W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2014

RE: SC failure for opening new window without prior notice ?

From: Hoffman, Allen <allen.hoffman@hq.dhs.gov>
Date: Wed, 9 Jul 2014 13:54:42 +0000
To: Jonathan Avila <jon.avila@ssbbartgroup.com>, Christophe Strobbe <strobbe@hdm-stuttgart.de>, "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
Message-ID: <F2EC405EEF0B414E8B1415742F1C8BEC476D070C@D2ASEPREA004>
If it’s a browser issue than this should be covered in user-agent accessibility requirements, not content.
I suppose I’m just poking something that is already done in SC(s) so should leave it alone—but in this case I’d suggest we don’t push failures too hard for something that seems to be a user-agent accessibility issue, or even more to the point a combination of user-agent and assistive technology issue than content issue.


From: Jonathan Avila [mailto:jon.avila@ssbbartgroup.com]
Sent: Wednesday, July 09, 2014 9:08 AM
To: Christophe Strobbe; w3c-wai-gl@w3.org
Subject: RE: SC failure for opening new window without prior notice ?


>  When you use magnification and a new screen pops up outside the magnified area, and you don't notice it because it's outside that area, isn't that an accessibility issue?

This sounds like a bug in the screen magnification software and should be reported to the vendor of the product.

Jonathan

From: Christophe Strobbe [mailto:strobbe@hdm-stuttgart.de<mailto:strobbe@hdm-stuttgart.de>]
Sent: Wednesday, July 09, 2014 8:59 AM
To: w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>
Cc: w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>
Subject: Re: SC failure for opening new window without prior notice ?


On 9/07/2014 14:53, Steve Faulkner wrote:
as a user you get nothing,
points to it being usability issue

If an issue disproportionately affects persons with disabilities, it is not just a usability issue. When you use magnification and a new screen pops up outside the magnified area, and you don't notice it because it's outside that area, isn't that an accessibility issue?

Best regards,

Christophe


--

Regards

SteveF
HTML 5.1<http://www.w3.org/html/wg/drafts/html/master/>

On 9 July 2014 13:44, Christophe Strobbe <strobbe@hdm-stuttgart.de<mailto:strobbe@hdm-stuttgart.de>> wrote:


On 9/07/2014 13:48, Hoffman, Allen wrote:
Heuristically speaking:
Why wouldn’t a blind user know a new window was opened?

In at least three screen readers I use I don’t seem to miss this information.

Standardsly speaking:
The window handle is available for assistive technology use from the OS or user-agent using the OS, so I’m not clear why this is a content issue and not a user-agent issue, especially since how such windows are handled is nearly universally configurable now in browsers.  Since the user-agent knows, the information is obviously available, so the assistive technology should be able to pick this up easily enough without specific additional content cues.


What am I missing?

If you argue only from the point of view of screen readers, you miss all other users with disabilities; screen reader users represent a minority of people with disabilities. That's why I checked what 7 different browsers do with 'target="_blank"'; as a sighted keyboard user, for example, you get exactly nothing. As a magnifier user, you get nothing.

Best regards,

Christophe







From: RichardWarren [mailto:richard.warren@userite.com]
Sent: Wednesday, July 09, 2014 7:05 AM
To: Aurélien Levy; w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>
Subject: Re: SC failure for opening new window without prior notice ?

Aurelien,

When a blind user activates a link that opens a new window without prior warning they do not know that a new window has been opened and thus their “browser history” renewed. Thus when they press the key for their screen reader to go back to the previous page nothing happens. Eventually they learn that we need to “close the current window” if we want to go back. However if they have followed as series of “blank-targets” this becomes a very hit-or-miss approach.

So in practical terms target="_blank" without a warning is a barrier and thus a failure of WCAG level A

SC 3.2.2 seems to cover this adequately. for example when it talks about form submission buttons being clearly marked as such, after all a form submission button is just a link to another page or state just as a target=”_blank”. The intention is clear here and it really is not practicable to provide examples of every possible situation where a change of context might be introduced. The over-riding essential is that the page operates in a predictable manner.

Richard



From: Aurélien Levy<mailto:aurelien.levy@temesis.com>
Sent: Wednesday, July 09, 2014 11:10 AM
To: w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>
Subject: Re: SC failure for opening new window without prior notice ?


Based on F37 alone, we cannot definitively conclude whether target="_blank" without a warning is a failure. It is just not part of *this* failure. In the absence of failure descriptions that specifically mention Aurélien's case, we have only the success criteria to go by. Whether this case fails SC 3.2.2 hinges on the interpretation of "changing the setting of any user interface component": does activating a link constitute a change in a setting? A link is a UI component, but does activating it constitute a change in its setting? (Nothing that you can retrieve from the DOM, as far as I know, unlike certain properties of form fields.) So it seems hard to argue that Aurélien's example fails SC 3.2.2.

However, the code fails SC3.2.5; there is even a failure for this: <http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140408/F22><http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140408/F22>.

Best regards,

Christophe
I agree with that but it strange because the understanding of 3.2.5 state :

Change on Request: Changes of context<http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-no-extreme-changes-context.html#context-changedef> are initiated only by user request or a mechanism<http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-no-extreme-changes-context.html#mechanismdef> is available to turn off such changes. (Level AAA)

and we have this Note: Clicking on a link is an example of an action that is "initiated only by user request."

So nothing ask about prior warning. It may be better to have something like :
Change on Request: Changes of context<http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-no-extreme-changes-context.html#context-changedef> are initiated only by user request with a prior warning or a mechanism<http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-no-extreme-changes-context.html#mechanismdef> is available to turn off such changes. (Level AAA)
or
Change on Request: Changes of context<http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-no-extreme-changes-context.html#context-changedef> are initiated only by user request or a mechanism<http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-no-extreme-changes-context.html#mechanismdef> is available to turn off, warn the the user of such changes. (Level AAA)

Regarding SC 2.4.4 I ask the question because there is an example of using title to warn the user of opening new windows http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140408/H33 so if not warning the user is not a failure of SC 2.4.4 maybe it's best to change this example as well

Aurélien


Richard Warren
Technical Manager
Website Auditing Limited (Userite)
http://www.userite.com





--

Christophe Strobbe

Akademischer Mitarbeiter

Adaptive User Interfaces Research Group

Hochschule der Medien

Nobelstraße 10

70569 Stuttgart

Tel. +49 711 8923 2749<tel:%2B49%20711%208923%202749>



"La vie est courte, hélas! et je n'ai pas encore lu tous mes livres!" (d'après Mallarmé).




--

Christophe Strobbe

Akademischer Mitarbeiter

Adaptive User Interfaces Research Group

Hochschule der Medien

Nobelstraße 10

70569 Stuttgart

Tel. +49 711 8923 2749



"La vie est courte, hélas! et je n'ai pas encore lu tous mes livres!" (d'après Mallarmé).
Received on Wednesday, 9 July 2014 13:55:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:34:15 UTC