E-mail List Archives

Re: Opening modal window without user action

for

From: Patrick H. Lauke
Date: Mar 31, 2016 2:43AM


On 31/03/2016 09:31, John Hicks wrote:
> Bruno
>
> ... I don't see how it doesn't fail 3.2.5
>
> For me it is a violation of this point (3.2.5)
>
> https://www.w3.org/TR/WCAG20-TECHS/F22.html

Splitting hairs, it's not a new window, but a modal dialog in the
current window.

P

>
> 2016-03-30 22:14 GMT+02:00 Bruno Girard < <EMAIL REMOVED> >:
>
>> Finally, what I take from these exchanges...
>> - WGAG has holes in it! Thanks Chaals for bringing it to WCAG group, I hope
>> something will happen in the near feature. :)
>> - Sadly, there is nothing at level A and AA that can stop us to display
>> modal windows after a delay even if the majority tells it is a very bad
>> practice and everyone wants to send unsolicited pop-ups to death....
>> - With AAA level, we can send people to jail... I will visit them and ask:
>> How expensive *were* your attorney fees?
>> - It is better to show modal pop-over at page loads, but unlike
>> helenkeller.org, we should never be able to navigate using keyboard on the
>> elements under the pop-over when it is displayed.
>> - I totally agree with Patrick: "Making the survey (as a modal, or as a
>> separate tab/window, or whatever) appear only as a result of a user
>> interaction on a link or clearly sign-posted button would be the
>> preferred/least problematic option of course".
>> - I continue to hate my actual pop-over after a delay modal solution. I
>> will work hard to have the budget to have this changed. I had like to have
>> a non-conformity argument thought...
>>
>> Should I take more?
>>
>> Thanks to everyone!
>>
>> Bruno
>>
>> 2016-03-29 6:41 GMT-04:00 Chaals McCathie Nevile < <EMAIL REMOVED> >:
>>
>>> On Fri, 25 Mar 2016 14:37:05 +0100, Patrick H. Lauke <
>>> <EMAIL REMOVED> > wrote:
>>>
>>> On 25/03/2016 11:18, Bruno Girard wrote:
>>>>
>>>>> Hello Rakesh,
>>>>> This change do not happen on focus... It is slightly different. We open
>>>>> the
>>>>> window and give focus to this window. This window appears after a
>>>>> programmed delay, without any specific user action. Does 3.2.1 is still
>>>>> the
>>>>> criteria to invoke for this fail?
>>>>>
>>>>
>>>> It appears that WCAG 2.0 does not have a very specific SC for unexpected
>>>> changes of context that happen without user action (be it input or
>> focus)
>>>> at AA.
>>>>
>>>
>>> Hmm.
>>>
>>> Agreed. I think this is a serious problem actually. I'll take it back to
>>> the WCAG group.
>>>
>>> For AAA, I'd say this falls foul of 3.2.5 Change on Request
>>>>
>> https://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-no-extreme-changes-context.html
>>>>
>>>
>>> Agreed.
>>>
>>> I think it also fails 2.2.4 - postpone time limits before they impact the
>>> user - again at AAA level,
>>> https://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-postponed.html
>>>
>>> Elsewhere in the thread at 15:20:22 +0100, Patrick H. Lauke <
>>> <EMAIL REMOVED> > wrote:
>>>
>>>> Ironically perhaps, I'd say that if the automatic popup happened right
>>>> away, and NOT after a timeout (so that the user didn't already start
>>>> interacting with the actual page, only to be unceremoniously and
>> unwantedly
>>>> being yanked off to this popup), then it would be less of a problem...
>>>>
>>>
>>> Right. In fact I think the case described in the failure technique at
>>> https://www.w3.org/TR/WCAG20-TECHS/F52.html *doesn't* violate WCAG 2.
>>>
>>> I raised an issue on that through the feedback form, but I have no idea
>>> whether that goes somewhere that it can be found by others. Anyone know?
>> Or
>>> should I duplicate it with a github issue?
>>>
>>> (this would also remove the problem/annoyance experienced by all users -
>>>> e.g. the "non disabled" mouse user who is starting to
>> read/interact/scroll
>>>> down on the page only to then be rudely presented with a doorslam modal;
>>>> this would also, of course, be a problem for users with cognitive
>>>> disabilities, or screen magnification, etc)
>>>>
>>>
>>> yeah, part of the problem here is that you think you're doing something,
>>> so you start a sequence of actions (navigation keystrokes, entering text
>>> through an IME, all kinds of oddness) but mid-way through they are
>> suddenly
>>> applied somewhere else.
>>>
>>> 3.3.4 and 3.3.6 - error prevention, limited for level AA and general for
>>> AAA, where actions that affect user data must be reversible or confirmed
>> -
>>> would apply in some of these cases, but the confusion effect isn't
>> handled
>>> automatically, so it depends on what happens in the modal popup and the
>>> webpage.
>>>
>>> cheers
>>>
>>> Chaals
>>>
>>> --
>>> Charles McCathie Nevile - web standards - CTO Office, Yandex
>>> <EMAIL REMOVED> - - - Find more at http://yandex.com
>>>
>>> >>> >>> >>> >>>
>> >> >> >> >>
> > > > >

--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke