E-mail List Archives

Re: Opening modal window without user action

for

From: Bruno Girard
Date: Mar 31, 2016 4:58AM


Sad that it doesn't fail any A or AA criteria.

For me, a new window is a new browser tab or instance. Not a modal window
for which the code is directly in the page where this window shows.

In F52 failure https://www.w3.org/TR/WCAG20-TECHS/F52.html, we can see in
one of the code example the line:

{ window.open('noscript.html', '_blank', 'height 0,width0'); }

JavaScript is something I understand just a little, so when I read
'_blank', sounds to me like an HTML target="_blank". The code examples has
their importance to my in the understanding of criterias, failures etc.

Bruno
Le 31 mars 2016 5:57 AM, "John Hicks" < <EMAIL REMOVED> > a écrit :

> apologies, I didn't see that Bruno's message was about A/AA only.
>
> .... ah, the evils of compliance :-)
>
>
>
> 2016-03-31 11:45 GMT+02:00 Patrick H. Lauke < <EMAIL REMOVED> >:
>
> > I think at this stage we have already established that the modal itself
> > fails 3.2.5 (AAA) - just not that specific *informative* example of
> failure
> > relating specifically to windows.
> >
> > P
> >
> >
> > On 31/03/2016 09:48, John Hicks wrote:
> >
> >> 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
> >>> > >>> > >>> > >>> > >>>
> >>> > >> > >> > >> > >>
> >>
> > --
> > 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
> > > > > > > > > >
> > > > >