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:31AM

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




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