E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 31 (In chronological order)

From: Bruno Girard
Date: Wed, Mar 23 2016 9:02AM
Subject: Opening modal window without user action
No previous message | Next message →

Hello,

I want to know, according to you, if the following behavior is a fail to
WCAG, if so, under which success criteria and why.

In our website, marketing wants to ask users if the want to answer a survey
after their visit.

The actual solution is a modal window that appears after a delay without
any user action. I agree that this is not the ideal solution but I have no
choice to deal with it. The actual modal window is not accessible, but in a
short term, as a quick win, I would make it accessible with the following
requirements (at the minimum):

1. Upon display, modal window container will received focus, this made
by Javascript.
2. What is under this window would not reachable when the modal is
displayed.
3. All the content in the window would be accessible.
4. In the modal, buttons Yes or No would be offerred at a question to
ask if user wants to answer a short survey at the end of his visit. Upon
click "Yes", a new browser Tab opens with survey and the modal window
close. User is notified of new window opening before click. Upon click
"No", the modal window close.
5. If possible, after modal window close, the focus will still be on the
same element before modal window automatic opening. Is it a fail if it
doesn't return to this element?

I have read this failure document:
https://www.w3.org/TR/WCAG20-TECHS/F52.html

I already know that it is a fail to open a new window upon load. In my
case, I have a delay. Does it fail?

Thanks in advance for your answers.

Happy Easter!

Bruno

From: Maxability Accessibility for all
Date: Thu, Mar 24 2016 7:01AM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

Hi Bruno,

I would still fail it under 3.2.1 On focus.
<http://www.maxability.co.in/2015/08/3-2-1-on-focus/>;

This behavior definitely disoriant the user . Getting focus back to the
triggering element might not be a WCAG violation but the focus should
return to a logical position which could be the triggering element or any
other logically positioned element such as the next focussable element to
the triggered one.


<http://www.maxability.co.in/2015/08/3-2-1-on-focus/>;
On <http://www.maxability.co.in/2015/08/3-2-1-on-focus/>;Wed, Mar 23, 2016
at 8:32 PM, Bruno Girard < = EMAIL ADDRESS REMOVED = > wrote:

> Hello,
>
> I want to know, according to you, if the following behavior is a fail to
> WCAG, if so, under which success criteria and why.
>
> In our website, marketing wants to ask users if the want to answer a survey
> after their visit.
>
> The actual solution is a modal window that appears after a delay without
> any user action. I agree that this is not the ideal solution but I have no
> choice to deal with it. The actual modal window is not accessible, but in a
> short term, as a quick win, I would make it accessible with the following
> requirements (at the minimum):
>
> 1. Upon display, modal window container will received focus, this made
> by Javascript.
> 2. What is under this window would not reachable when the modal is
> displayed.
> 3. All the content in the window would be accessible.
> 4. In the modal, buttons Yes or No would be offerred at a question to
> ask if user wants to answer a short survey at the end of his visit. Upon
> click "Yes", a new browser Tab opens with survey and the modal window
> close. User is notified of new window opening before click. Upon click
> "No", the modal window close.
> 5. If possible, after modal window close, the focus will still be on the
> same element before modal window automatic opening. Is it a fail if it
> doesn't return to this element?
>
> I have read this failure document:
> https://www.w3.org/TR/WCAG20-TECHS/F52.html
>
> I already know that it is a fail to open a new window upon load. In my
> case, I have a delay. Does it fail?
>
> Thanks in advance for your answers.
>
> Happy Easter!
>
> Bruno
> > > > >

From: Bruno Girard
Date: Fri, Mar 25 2016 5:18AM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

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?
Thanks,

Bruno
Le 24 mars 2016 9:01 AM, "Maxability Accessibility for all" <
= EMAIL ADDRESS REMOVED = > a écrit :

> Hi Bruno,
>
> I would still fail it under 3.2.1 On focus.
> <http://www.maxability.co.in/2015/08/3-2-1-on-focus/>;
>
> This behavior definitely disoriant the user . Getting focus back to the
> triggering element might not be a WCAG violation but the focus should
> return to a logical position which could be the triggering element or any
> other logically positioned element such as the next focussable element to
> the triggered one.
>
>
> <http://www.maxability.co.in/2015/08/3-2-1-on-focus/>;
> On <http://www.maxability.co.in/2015/08/3-2-1-on-focus/>;Wed, Mar 23, 2016
> at 8:32 PM, Bruno Girard < = EMAIL ADDRESS REMOVED = > wrote:
>
> > Hello,
> >
> > I want to know, according to you, if the following behavior is a fail to
> > WCAG, if so, under which success criteria and why.
> >
> > In our website, marketing wants to ask users if the want to answer a
> survey
> > after their visit.
> >
> > The actual solution is a modal window that appears after a delay without
> > any user action. I agree that this is not the ideal solution but I have
> no
> > choice to deal with it. The actual modal window is not accessible, but
> in a
> > short term, as a quick win, I would make it accessible with the following
> > requirements (at the minimum):
> >
> > 1. Upon display, modal window container will received focus, this made
> > by Javascript.
> > 2. What is under this window would not reachable when the modal is
> > displayed.
> > 3. All the content in the window would be accessible.
> > 4. In the modal, buttons Yes or No would be offerred at a question to
> > ask if user wants to answer a short survey at the end of his visit.
> Upon
> > click "Yes", a new browser Tab opens with survey and the modal window
> > close. User is notified of new window opening before click. Upon click
> > "No", the modal window close.
> > 5. If possible, after modal window close, the focus will still be on
> the
> > same element before modal window automatic opening. Is it a fail if it
> > doesn't return to this element?
> >
> > I have read this failure document:
> > https://www.w3.org/TR/WCAG20-TECHS/F52.html
> >
> > I already know that it is a fail to open a new window upon load. In my
> > case, I have a delay. Does it fail?
> >
> > Thanks in advance for your answers.
> >
> > Happy Easter!
> >
> > Bruno
> > > > > > > > > >
> > > > >

From: Maxability Accessibility for all
Date: Fri, Mar 25 2016 6:32AM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

Hi Bruno,

I believe it's a definite 3.2.1 violation. Lets see what others has to say.

On Fri, Mar 25, 2016 at 4:48 PM, Bruno Girard < = EMAIL ADDRESS REMOVED = >
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?
> Thanks,
>
> Bruno
> Le 24 mars 2016 9:01 AM, "Maxability Accessibility for all" <
> = EMAIL ADDRESS REMOVED = > a écrit :
>
> > Hi Bruno,
> >
> > I would still fail it under 3.2.1 On focus.
> > <http://www.maxability.co.in/2015/08/3-2-1-on-focus/>;
> >
> > This behavior definitely disoriant the user . Getting focus back to the
> > triggering element might not be a WCAG violation but the focus should
> > return to a logical position which could be the triggering element or any
> > other logically positioned element such as the next focussable element to
> > the triggered one.
> >
> >
> > <http://www.maxability.co.in/2015/08/3-2-1-on-focus/>;
> > On <http://www.maxability.co.in/2015/08/3-2-1-on-focus/>;Wed, Mar 23,
> 2016
> > at 8:32 PM, Bruno Girard < = EMAIL ADDRESS REMOVED = > wrote:
> >
> > > Hello,
> > >
> > > I want to know, according to you, if the following behavior is a fail
> to
> > > WCAG, if so, under which success criteria and why.
> > >
> > > In our website, marketing wants to ask users if the want to answer a
> > survey
> > > after their visit.
> > >
> > > The actual solution is a modal window that appears after a delay
> without
> > > any user action. I agree that this is not the ideal solution but I have
> > no
> > > choice to deal with it. The actual modal window is not accessible, but
> > in a
> > > short term, as a quick win, I would make it accessible with the
> following
> > > requirements (at the minimum):
> > >
> > > 1. Upon display, modal window container will received focus, this
> made
> > > by Javascript.
> > > 2. What is under this window would not reachable when the modal is
> > > displayed.
> > > 3. All the content in the window would be accessible.
> > > 4. In the modal, buttons Yes or No would be offerred at a question
> to
> > > ask if user wants to answer a short survey at the end of his visit.
> > Upon
> > > click "Yes", a new browser Tab opens with survey and the modal
> window
> > > close. User is notified of new window opening before click. Upon
> click
> > > "No", the modal window close.
> > > 5. If possible, after modal window close, the focus will still be on
> > the
> > > same element before modal window automatic opening. Is it a fail if
> it
> > > doesn't return to this element?
> > >
> > > I have read this failure document:
> > > https://www.w3.org/TR/WCAG20-TECHS/F52.html
> > >
> > > I already know that it is a fail to open a new window upon load. In my
> > > case, I have a delay. Does it fail?
> > >
> > > Thanks in advance for your answers.
> > >
> > > Happy Easter!
> > >
> > > Bruno
> > > > > > > > > > > > > > >
> > > > > > > > > >
> > > > >

From: Patrick H. Lauke
Date: Fri, Mar 25 2016 7:37AM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

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

At a stretch, 2.2.1 Timing Adjustable
https://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-required-behaviors.html
(A) and 2.2.4 Interruptions
https://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-postponed.html
(again AAA)

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

From: John Hicks
Date: Fri, Mar 25 2016 8:12AM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

Hello WebAIM team...

Definitely 3.2.5 violation and may I just say, "death to unsolicited
pop-ups!". Sorry if I appear harsh...

Not that this helps with the violation but does this modal close with the
ESCape key, or do you have to go through the YES / NO ?

If we can get rid of it without having to interact with it that is at least
slightly better (for the user).

John




2016-03-25 14:37 GMT+01:00 Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >:

> 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. 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
>
> At a stretch, 2.2.1 Timing Adjustable
> https://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-required-behaviors.html
> (A) and 2.2.4 Interruptions
> https://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-postponed.html
> (again AAA)
>
> P
> --
> 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
>
> > > > >

From: John Hicks
Date: Fri, Mar 25 2016 8:13AM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

... I'd add that it is not realle 3.2.1 because, as Bruno has stated, the
pop-up is not displayed upon a shift of focus

From: Mike Barlow
Date: Fri, Mar 25 2016 8:15AM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

I agree with Patrick. Though I'd never design a site that has an
"automatic" popup like the op describes. Sometimes one must bow to he who
signs the paycheck, but also sometimes he who signs the paycheck can be
persuaded that his approach could lead to more problems than it's worth.

For example, I've had many a customer tell me the "it's too costly (in
either time or money) to make my site accessible" to which I usually
respond (very politely of course), "Ok, so how expensive *is* a lawsuit
these days?" Citing cases where companies have had to pay out on
multi-million dollar lawsuits and STILL make their sites accessible.

*Mike Barlow*
Lead Application Developer
Web Accessibility/Section 508 SME

Lancaster, Pa 17601
Office: 732.784.3047
Cell: 732.682.8226
e-mail: = EMAIL ADDRESS REMOVED =

On Fri, Mar 25, 2016 at 9:37 AM, Patrick H. Lauke < = EMAIL ADDRESS 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. 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
>
> At a stretch, 2.2.1 Timing Adjustable
> https://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-required-behaviors.html
> (A) and 2.2.4 Interruptions
> https://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-postponed.html
> (again AAA)
>
> P
> --
> 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
>
> > > > >

From: Patrick H. Lauke
Date: Fri, Mar 25 2016 8:20AM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

On 25/03/2016 14:15, Mike Barlow wrote:
> I agree with Patrick. Though I'd never design a site that has an
> "automatic" popup like the op describes. Sometimes one must bow to he who
> signs the paycheck, but also sometimes he who signs the paycheck can be
> persuaded that his approach could lead to more problems than it's worth.

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... (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)

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

From: Mike Barlow
Date: Fri, Mar 25 2016 8:27AM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

Hmmm Patrick, I forgot about the "time delay" aspect of the popup. And
you're right I hate being in the middle of something and then this popup
appears (I just was browsing a site when that exact thing happened, right
in the middle of reading this huge ad popped up and didn't even have the
courtesy of displaying a "get me out of here" button (I had to, correctly,
assume that ESC would close the popup).

*Mike Barlow*
Lead Application Developer
Web Accessibility/Section 508 SME

Lancaster, Pa 17601
Office: 732.784.3047
Cell: 732.682.8226
e-mail: = EMAIL ADDRESS REMOVED =

On Fri, Mar 25, 2016 at 10:20 AM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:

> On 25/03/2016 14:15, Mike Barlow wrote:
>
>> I agree with Patrick. Though I'd never design a site that has an
>> "automatic" popup like the op describes. Sometimes one must bow to he who
>> signs the paycheck, but also sometimes he who signs the paycheck can be
>> persuaded that his approach could lead to more problems than it's worth.
>>
>
> 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...
> (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)
>
>
> P
> --
> 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
> > > > >

From: Maxability Accessibility for all
Date: Sun, Mar 27 2016 11:56PM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

So you say 3.2.1 is violated only if the modal opens immediately when user
focus on to the element? Just to understand out of my ignorance.



On Fri, Mar 25, 2016 at 7:50 PM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:

> On 25/03/2016 14:15, Mike Barlow wrote:
>
>> I agree with Patrick. Though I'd never design a site that has an
>> "automatic" popup like the op describes. Sometimes one must bow to he who
>> signs the paycheck, but also sometimes he who signs the paycheck can be
>> persuaded that his approach could lead to more problems than it's worth.
>>
>
> 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...
> (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)
>
>
> P
> --
> 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
> > > > >

From: Patrick H. Lauke
Date: Mon, Mar 28 2016 2:21AM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

On 28/03/2016 06:56, Maxability Accessibility for all wrote:
> So you say 3.2.1 is violated only if the modal opens immediately when user
> focus on to the element? Just to understand out of my ignorance.

"3.2.1 On Focus: When any component receives focus, it does not initiate
a change of context. (Level A)"

So yes, only when a component receives focus.

And similarly, this can't be failed under "3.2.2 On Input: Changing the
setting of any user interface component does not automatically cause a
change of context unless the user has been advised of the behavior
before using the component. (Level A)" because that is about a user
interacting with an interface component (e.g. a <select>, radio button,
checkbox...anything that traditionally doesn't result in a change of
context).

P

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

From: Ajay Sharma
Date: Mon, Mar 28 2016 3:47AM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

Hi, just to be curious, what is the best way to accomplish what Bruno
is trying to achieve?
What if instead of showing page with mobile window, the user is
redirected to the survey page with a easily distinguishable link to
skip the survey on the top? This holds for if the page comes in the
sequence of some process.
Otherwise, if it is independent single page, how about putting link to
survey at some well designed heading or making an accessible banner
linked to survey page?

I read somewhere that 98 percent of the internet users hate pop-ups.

On 3/28/16, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>
>
> On 28/03/2016 06:56, Maxability Accessibility for all wrote:
>> So you say 3.2.1 is violated only if the modal opens immediately when
>> user
>> focus on to the element? Just to understand out of my ignorance.
>
> "3.2.1 On Focus: When any component receives focus, it does not initiate
> a change of context. (Level A)"
>
> So yes, only when a component receives focus.
>
> And similarly, this can't be failed under "3.2.2 On Input: Changing the
> setting of any user interface component does not automatically cause a
> change of context unless the user has been advised of the behavior
> before using the component. (Level A)" because that is about a user
> interacting with an interface component (e.g. a <select>, radio button,
> checkbox...anything that traditionally doesn't result in a change of
> context).
>
> P
>
> --
> 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
> > > > >

From: Patrick H. Lauke
Date: Mon, Mar 28 2016 4:45AM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

On 28/03/2016 10:47, Ajay Sharma wrote:
> Hi, just to be curious, what is the best way to accomplish what Bruno
> is trying to achieve?
> What if instead of showing page with mobile window, the user is
> redirected to the survey page with a easily distinguishable link to
> skip the survey on the top? This holds for if the page comes in the
> sequence of some process.

If the redirect happens after a certain timeout/delay (which is what,
from what I understand, is happening with the modal just now), then it's
the same kind of problem....a change of context that is not the result
of an explicit user action.

If the redirect happens right away, it's less of a problem. But the same
is also true for the modal (if it's shown, and user is taken to it, as
soon as the page is loaded, and not after a delay).

> Otherwise, if it is independent single page, how about putting link to
> survey at some well designed heading or making an accessible banner
> linked to survey page?

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.

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

From: Marc Solomon
Date: Mon, Mar 28 2016 12:38PM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

I recently visited the Helen Keller National Center in New York. Prior to my meeting, I reviewed their newly redesigned (hellenkeller.org). First time visitors are presented with a message about website features for customizing the visual appearance of the content. The visible message container has a prominent location in the top left of the screen and all other background content is dimmed. The message content is placed near the top of the DOM so screen reader users discover the message as soon as you start reading the page. There is a Close Menu element at the end of the message that is keyboard operable and clicking outside of the message container also closes it. I am curious to know what others think of this implementation and if it could serve as a model for the types of modals we have been discussing on this thread.

Thanks,
Marc

From: Patrick H. Lauke
Date: Mon, Mar 28 2016 3:26PM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

On 28/03/2016 19:38, Marc Solomon wrote:
> I recently visited the Helen Keller National Center in New York.
> Prior to my meeting, I reviewed their newly redesigned
> (hellenkeller.org). First time visitors are presented with a message
> about website features for customizing the visual appearance of the
> content. The visible message container has a prominent location in
> the top left of the screen and all other background content is
> dimmed. The message content is placed near the top of the DOM so
> screen reader users discover the message as soon as you start reading
> the page. There is a Close Menu element at the end of the message
> that is keyboard operable and clicking outside of the message
> container also closes it. I am curious to know what others think of
> this implementation and if it could serve as a model for the types of
> modals we have been discussing on this thread.

It is not the modal itself, and how it is implemented, that's the main
problem in this case though. It's the fact that it's being displayed
(and yanks focus away) after a set timeout after the page has been loaded.

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

From: Marc Solomon
Date: Mon, Mar 28 2016 4:45PM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

On March 28, 2016 5:29:12 PM "Patrick H. Lauke" < = EMAIL ADDRESS REMOVED = > wrote:

"It's the fact that it's being displayed
(and yanks focus away) after a set timeout after the page has been loaded."

Agreed, and is why I thought the example on hellenkeller.org might serve as a model for how and more specifically when to display a pop up modal that was not explicitly opened by the user. That is, on page load for first time visitors.
Best,
Marc



Sent with AquaMail for Android
http://www.aqua-mail.com

From: John Hicks
Date: Tue, Mar 29 2016 1:43AM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

Yes, the only way to have this information at the beginning of the user
session is to display it on page load immediately.

Of course , it is probably true that more users will abandon in the case of
immediate pop-up and having the time delay is seen as a reassurance that
"the info you want is here, but first a word from our survey team" ....
dismissing a pop up is easy after all (if you are a sighted user and the
Escape key is working).

What this site really needs to do is use a different technique, such as a
cookie that loads the modal for a repeat visitor on his or her second visit
(or in the event of a subsequent page load) ... so much less intrusive.

Intuitively I think users are very sensitive to the manipulation of their
attention.

This modal could also be posted when the tab/window is closed... ie after
the user has already been on the site for a while.

John


2016-03-29 0:45 GMT+02:00 Marc Solomon < = EMAIL ADDRESS REMOVED = >:

> On March 28, 2016 5:29:12 PM "Patrick H. Lauke" < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> "It's the fact that it's being displayed
> (and yanks focus away) after a set timeout after the page has been loaded."
>
> Agreed, and is why I thought the example on hellenkeller.org might serve
> as a model for how and more specifically when to display a pop up modal
> that was not explicitly opened by the user. That is, on page load for first
> time visitors.
> Best,
> Marc
>
>
>
> Sent with AquaMail for Android
> http://www.aqua-mail.com
> > > > >

From: Chaals McCathie Nevile
Date: Tue, Mar 29 2016 4:41AM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

On Fri, 25 Mar 2016 14:37:05 +0100, Patrick H. Lauke
< = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = - - - Find more at http://yandex.com

From: Bruno Girard
Date: Wed, Mar 30 2016 1:44PM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

"This modal could also be posted when the tab/window is closed... ie after
the user has already been on the site for a while"

Can you tell how we do this and if it would violate a WCAG 2.0 criteria?

2016-03-29 3:43 GMT-04:00 John Hicks < = EMAIL ADDRESS REMOVED = >:

> Yes, the only way to have this information at the beginning of the user
> session is to display it on page load immediately.
>
> Of course , it is probably true that more users will abandon in the case of
> immediate pop-up and having the time delay is seen as a reassurance that
> "the info you want is here, but first a word from our survey team" ....
> dismissing a pop up is easy after all (if you are a sighted user and the
> Escape key is working).
>
> What this site really needs to do is use a different technique, such as a
> cookie that loads the modal for a repeat visitor on his or her second visit
> (or in the event of a subsequent page load) ... so much less intrusive.
>
> Intuitively I think users are very sensitive to the manipulation of their
> attention.
>
> This modal could also be posted when the tab/window is closed... ie after
> the user has already been on the site for a while.
>
> John
>
>
> 2016-03-29 0:45 GMT+02:00 Marc Solomon < = EMAIL ADDRESS REMOVED = >:
>
> > On March 28, 2016 5:29:12 PM "Patrick H. Lauke" < = EMAIL ADDRESS REMOVED = >
> > wrote:
> >
> > "It's the fact that it's being displayed
> > (and yanks focus away) after a set timeout after the page has been
> loaded."
> >
> > Agreed, and is why I thought the example on hellenkeller.org might serve
> > as a model for how and more specifically when to display a pop up modal
> > that was not explicitly opened by the user. That is, on page load for
> first
> > time visitors.
> > Best,
> > Marc
> >
> >
> >
> > Sent with AquaMail for Android
> > http://www.aqua-mail.com
> > > > > > > > > >
> > > > >

From: Mike Barlow
Date: Wed, Mar 30 2016 1:50PM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

Marc, when I clicked on the link you provided it went to a "domain parking"
site. A quick google search got me to the actual link which is:
https://www.helenkeller.org/hknc (don't know why the difference that should
make no difference made a difference, but it did).

*Mike Barlow*
Web Application Developer
Web Accessibility/Section 508 SME

Lancaster, Pa 17601
Office: 732.835-7557
Cell: 732.682.8226
e-mail: = EMAIL ADDRESS REMOVED =

On Mon, Mar 28, 2016 at 2:38 PM, Marc Solomon < = EMAIL ADDRESS REMOVED = >
wrote:

> I recently visited the Helen Keller National Center in New York. Prior to
> my meeting, I reviewed their newly redesigned (hellenkeller.org). First
> time visitors are presented with a message about website features for
> customizing the visual appearance of the content. The visible message
> container has a prominent location in the top left of the screen and all
> other background content is dimmed. The message content is placed near the
> top of the DOM so screen reader users discover the message as soon as you
> start reading the page. There is a Close Menu element at the end of the
> message that is keyboard operable and clicking outside of the message
> container also closes it. I am curious to know what others think of this
> implementation and if it could serve as a model for the types of modals we
> have been discussing on this thread.
>
> Thanks,
> Marc
>
>

From: Marc Solomon
Date: Wed, Mar 30 2016 1:57PM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

There was a typo in the URL (an extra l in helen). Sorry about that and thanks Google for leading people to the intended site.

Marc

From: Bruno Girard
Date: Wed, Mar 30 2016 1:56PM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

I think http://helenkeller.org/ pop up modal cannot be taken as a model.
With keyboard and screen reader, I was able to navigate everywhere on the
page, without closing the pop over, event in the content behind the gray
shadow. In my view, all elements which aren't in the pop over needs to be
unreachable when the pop over is displayed.

Also, in this site, the navigation item "Viewing Options" is coded has an
hyperlink, but it's interaction results in showing a pop over. In my mind,
this has to be a button, not an hyperlink.

I would like to thank everyone for the time and energy to answer my
question.
Thanks Bruno

2016-03-28 18:45 GMT-04:00 Marc Solomon < = EMAIL ADDRESS REMOVED = >:

> On March 28, 2016 5:29:12 PM "Patrick H. Lauke" < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> "It's the fact that it's being displayed
> (and yanks focus away) after a set timeout after the page has been loaded."
>
> Agreed, and is why I thought the example on hellenkeller.org might serve
> as a model for how and more specifically when to display a pop up modal
> that was not explicitly opened by the user. That is, on page load for first
> time visitors.
> Best,
> Marc
>
>
>
> Sent with AquaMail for Android
> http://www.aqua-mail.com
> > > > >

From: Bruno Girard
Date: Wed, Mar 30 2016 2:14PM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

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 ADDRESS REMOVED = >:

> On Fri, 25 Mar 2016 14:37:05 +0100, Patrick H. Lauke <
> = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = - - - Find more at http://yandex.com
>
> > > > >

From: John Hicks
Date: Thu, Mar 31 2016 2:31AM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED = >:
>
> > On Fri, 25 Mar 2016 14:37:05 +0100, Patrick H. Lauke <
> > = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = - - - Find more at http://yandex.com
> >
> > > > > > > > > >
> > > > >

From: Patrick H. Lauke
Date: Thu, Mar 31 2016 2:43AM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED = >:
>>
>>> On Fri, 25 Mar 2016 14:37:05 +0100, Patrick H. Lauke <
>>> = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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

From: John Hicks
Date: Thu, Mar 31 2016 2:48AM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>>> >:
>>>
>>> On Fri, 25 Mar 2016 14:37:05 +0100, Patrick H. Lauke <
>>>> = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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
> > > > >

From: Patrick H. Lauke
Date: Thu, Mar 31 2016 3:45AM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>>>>> :
>>>>
>>>> On Fri, 25 Mar 2016 14:37:05 +0100, Patrick H. Lauke <
>>>>> = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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

From: John Hicks
Date: Thu, Mar 31 2016 3:57AM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>>>>>
>>>>>> :
>>>>>>
>>>>>
>>>>> On Fri, 25 Mar 2016 14:37:05 +0100, Patrick H. Lauke <
>>>>>
>>>>>> = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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
> > > > >

From: Bruno Girard
Date: Thu, Mar 31 2016 4:58AM
Subject: Re: Opening modal window without user action
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
> >>>>>
> >>>>>> :
> >>>>>>
> >>>>>
> >>>>> On Fri, 25 Mar 2016 14:37:05 +0100, Patrick H. Lauke <
> >>>>>
> >>>>>> = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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
> > > > > > > > > >
> > > > >

From: Tel Woolsey
Date: Thu, Mar 31 2016 11:15AM
Subject: Re: Opening modal window without user action (Bruno Girard)
← Previous message | No next message

On Mar 31, 2016, at 10:02 AM, = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = > wrote:

Re: Opening modal window without user action (Bruno Girard)