WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Opening modal window without user action

for

From: John Hicks
Date: Mar 31, 2016 2:48AM

Well, it is about change of context, surely ....

I guess it could depend on what you mean by "New window" ... in the SC we
read :

"New windows take the focus away from what the user is reading or doing."

"The failure comes when pop-ups appear unexpectedly."

... .seems pretty applicable to me.

2016-03-31 10:43 GMT+02:00 Patrick H. Lauke < <EMAIL REMOVED> >:

>
>
> 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
> > > > >