- From: Katie Haritos-Shea <ryladog@gmail.com>
- Date: Wed, 9 Jul 2014 13:04:16 -0400
- To: Jonathan Avila <jon.avila@ssbbartgroup.com>
- Cc: Christophe Strobbe <strobbe@hdm-stuttgart.de>, WCAG <w3c-wai-gl@w3.org>
- Message-ID: <CAEy-OxFJ53D9k-N+ciOnPsEVBiFHaYucSTWjPY6=G47kBQcvBg@mail.gmail.com>
In my mind, the normative reference WCAG 2 says "3.2.2 <http://www.w3.org/TR/WCAG20/#consistent-behavior-unpredictable-change> Changing the setting of any user interface component <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#user-interface-componentdef> does not automatically cause a change of context <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#context-changedef> unless the user has been advised of the behavior before using the component. *(Level A)*" On that page the user interface component <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#user-interface-componentdef> definition has "*Note 2: *User interface components include form elements and links as well as components generated by scripts." In the case where that link opens a new window or scripted overlay, and this is not identified, I would interpret this to be a clear fail of 3.3.2 if the user is not notified in advance (by AT/UA and/or with programmatically associated text). Clicking on a link is changing the link setting/state to active - and a/the back button will not return the user to where they were if/when activated. I would not rely on the How to Meet, Understanding or Techniques docs for this answer because there is conflicting information within those documents and they are not the normative reference. Which takes me back to the WCAG 2 Standard requirement where it is clear that a link is a UI component. UA or AT issue aside.... ** katie ** Katie Haritos-Shea Senior Accessibility SME (WCAG/Section 508/ADA) 703-371-5545 ryladog@gmail.com People may forget exactly what it was that you said or did, but people will never forget how you made them feel....... Our scars remind us of where we have been........they do not have to dictate where we are going. On Wed, Jul 9, 2014 at 9:08 AM, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote: > Ø 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] > *Sent:* Wednesday, July 09, 2014 8:59 AM > *To:* w3c-wai-gl@w3.org > *Cc:* 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> 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 > <richard.warren@userite.com>] > *Sent:* Wednesday, July 09, 2014 7:05 AM > *To:* Aurélien Levy; 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 <aurelien.levy@temesis.com> > > *Sent:* Wednesday, July 09, 2014 11:10 AM > > *To:* 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 > > > > "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 17:04:46 UTC