- From: Ramón Corominas <listas@ramoncorominas.com>
- Date: Sun, 27 Jul 2014 18:33:51 +0200
- To: Userite <richard@userite.com>
- CC: "Aubrey, Richard" <richard.aubrey@rbc.com>, "'Paul J. Adam'" <paul.adam@deque.com>, 'Phill Jenkins' <pjenkins@us.ibm.com>, w3c-wai-ig@w3.org
Hello, Richard. In principle, activating a link or pressing a button is not considered "changing the setting of any user interface component". Indeed, if you follow a link to another page you will always have a change of context. A better example of a failure of 3.2.2 would be using a select that redirects automatically to another page (or reloads the current one) when you just change the selected option without confirming it with an "action" component such as a button or link. In any case, if a link opens in a new window but does not offer information to anyone it would probably be a usability issue more than an accessibility one, since no one would know about the new window, and many people would find it confusing even if they don't have a disability. Regards, Ramón. Richard wrote: > I have always understood that 3.2.2 (on input) covers this situation > when it says > (http://www.w3.org/TR/WCAG20/#consistent-behavior-unpredictable-change) > “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) “ > > According to the guideline definitions “change of context” > (http://www.w3.org/TR/WCAG20/#context-changedef) = > > Changes in context include changes of: > 1. user agent; > 2. *viewport**;* > > Furthermore “Viewport” is defined as > (http://www.w3.org/TR/WCAG20/#viewportdef) > “object in which the user agent presents content > /Note 1: /The user agent presents content through one or more viewports. > Viewports include windows, frames, loudspeakers, and virtual magnifying > glasses. A viewport may contain another viewport (e.g., nested frames). > Interface components created by the user agent such as prompts, menus, > and alerts are not viewports. “ > > So if a link opens a new window without warning it surely fails 3.2.2 as > it moves the viewport to a new window. > > Fortunately it is quite easy to warn users if a new window will open > using either text or an icon with alt text WITHIN the link text. > > When we come to 3.2.5 (which is AAA level) the guidelines are asking > that such change of context (even with a warning) can be avoided by the > user either by not requesting the change, or a mechanism exists that > allows the user to turn of such changes (i.e by default). This implies > that any pages that are targeted by “new window” links are also > available via links that do not open new windows at all (maintaining a > consistent browsing platform). > > Regards > Richard Warren > Technical Manager > http://www.userite.com > ----------------------------------------------------------------------------- > > *From:* Aubrey, Richard <mailto:richard.aubrey@rbc.com> > *Sent:* Tuesday, July 22, 2014 3:28 PM > *To:* 'Paul J. Adam' <mailto:paul.adam@deque.com> ; 'Phill Jenkins' > <mailto:pjenkins@us.ibm.com> > *Cc:* mailto:w3c-wai-ig@w3.org > *Subject:* RE: Q: Change on Request 3.2.5? Is warning required for links > that open new windows? > > Hi, > From my perspective, this warning comes in handy for users who are > blind and are working in an application window. opening additional > windows makes it confusing in navigation back to the application and > difficult to know when you close the window (ALT F4) whether you are > closing the application or just the additional window that has been opened. > > > Richard Aubrey | Manager, RBC IT Accessibility & National Co-Chair RBC > REACH ERG for People With Disabilities, Enterprise Architecture Office > (EAO) | Technology & Operations |* RBC Royal Bank* | 416-348-2926 > > > > ------------------------------------------------------------------------ > *From:* Paul J. Adam [mailto:paul.adam@deque.com] > *Sent:* Monday, 21 July, 2014 5:04 PM > *To:* Phill Jenkins > *Cc:* w3c-wai-ig@w3.org Group > *Subject:* Re: Q: Change on Request 3.2.5? Is warning required for links > that open new windows? > > Thanks for the feedback Phill! Since this is AAA I've never actually > worked with it because clients only request AA. > > I think it should only be required for cases like modal dialogs where > the browser or AT can't detect the target attribute. > > Safari for OS X warns you in the status bar if the link is going to open > a new tab. No other browsers I tested did this. > > For Usability I think those link icons with alt should be required for > new windows, file types, etc. > > Paul J. Adam > Accessibility Evangelist > www.deque.com <http://www.deque.com> > > On Jul 17, 2014, at 11:59 AM, Phill Jenkins <pjenkins@us.ibm.com > <mailto:pjenkins@us.ibm.com>> wrote: > >> Paul said: ". . . So reading that portion I don't see how it applies >> to links because the user is actively "requesting" (clicking on the >> link) and links do happen to open in new windows often for all users." >> >> I believe the intent of 3.2.5 AAA is to inform the user whether >> clicking the link will open a _new window_ or whether it will simply >> load a new page in the _existing window_. In other words, how does >> the user predict what will happen when the link is clicked - whether a >> new window is opened or not.? new window = change of context. We see >> these little icons next to links all the time indicating which ones >> open new windows, or change web sites, etc. helping the user predict >> how it will operate. 3.2.5 AAA has to be read in context with the >> whole 3.2 guideline and the other four success criteria in it. >> *Guideline 3.2 Predictable: Make Web pages appear and operate in >> predictable ways. * >> I would NOT recommend reading or trying to interpret each success >> criteria without considering the other success criteria in the >> guideline. >> >> The other "context" needed for correctly interpreting the success >> criteria (in my opinion) is to consider the role of the user agent, >> assistive technology, and user settings. Does the browser have a >> responsibility to warn the user by having a setting to allow it to >> warn the user that a new window (change of context) will happen? If >> the user isn't using a browser capable (e.g. older version , etc.), or >> if the user hasn't set the setting due to lack of training, then the >> working group added some of these tripple A success criteria to >> compensate for lack of conformance of user agents with UAAG 2.0 and/or >> lack of training of users to use their assistive technology and/or >> potential conflicts as mentioned. >> ____________________________________________ >> Regards, >> Phill Jenkins, >> Senior Accessibility Engineer & Business Development Executive >> IBM Research - Human Ability & Accessibility Center >> http://www.ibm.com/able >> http://www.facebook.com/IBMAccessibility >> http://twitter.com/IBMAccess >> http://www.linkedin.com/in/philljenkins >> >> >> >> From: "Paul J. Adam" <paul.adam@deque.com >> <mailto:paul.adam@deque.com>> >> To: "w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> Group" >> <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org>>, >> Date: 07/17/2014 09:09 AM >> Subject: Q: Change on Request 3.2.5? Is warning required for >> links that open new windows? >> ------------------------------------------------------------------------ >> >> >> >> Can I get some help interpreting WCAG AAA please? I still don't see >> where the normative requirements state that links which open new >> windows must have a warning to pass AAA. >> >> <_http://www.w3.org/TR/2014/NOTE-UNDERSTANDING-WCAG20-20140311/consistent-behavior-no-extreme-changes-context.html_> >> >> >> Some pasted snippets<snip> out of the understanding document: >> >> <snip> >> Change on Request: >> Understanding SC 3.2.5 >> 3.2.5 Change on Request: Changes of context are initiated only by user >> request or a mechanism is available to turn off such changes. (Level AAA) >> </snip> >> >> <snip> >> This Success Criterion aims to eliminate potential confusion that may >> be caused by unexpected changes of context such as automatic launching >> of new windows >> </snip> >> >> <snip> >> Note: Clicking on a link is an example of an action that is "initiated >> only by user request." >> </snip> >> >> So reading that portion I don't see how it applies to links because >> the user is actively "requesting" (clicking on the link) and links do >> happen to open in new windows often for all users. I see this >> requirement as more for pop ups that jump out of nowhere with no >> action taken by the user or when a stupid news site forces a page >> reload to add new articles and the user's focus is lost. >> >> However, it does mention in the techniques F22: Failure of Success >> Criterion 3.2.5 due to opening windows that are not requested by the >> user which reads: >> <_http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140311/F22_> >> >> <snip> >> Failure due to opening new windows when the user does not expect them. >> New windows take the focus away from what the user is reading or >> doing. This is fine when the user has interacted with a piece of User >> Interface and expects to get a new window, such as an options >> dialogue. The failure comes when pop-ups appear unexpectedly. >> </snip> >> >> <snip> >> Failure Example 2: >> >> A user clicks on a link, and a new window appears. The original link >> has no associated text saying that it will open a new window. >> </snip> >> >> I only see this requirement specified in the techniques but then I see >> it says techniques are informative: >> >> <snip> >> Techniques are informative—that means they are not required. The basis >> for determining conformance to WCAG 2.0 is the success criteria >> </snip> >> >> So Techniques are not required but if you fail a Failure Technique >> that means you always fail, even though it's a technique, which is not >> required? I'm confused. >> >> Thanks! >> >> Paul J. Adam >> Accessibility Evangelist >> _www.deque.com_ <http://www.deque.com/> >> > > _______________________________________________________________________ > > If you received this email in error, please advise the sender (by return > email or otherwise) immediately. You have consented to receive the > attached electronically at the above-noted email address; please retain > a copy of this confirmation for future reference. > > Si vous recevez ce courriel par erreur, veuillez en aviser l'expéditeur > immédiatement, par retour de courriel ou par un autre moyen. Vous avez > accepté de recevoir le(s) document(s) ci-joint(s) par voie électronique > à l'adresse courriel indiquée ci-dessus; veuillez conserver une copie de > cette confirmation pour les fins de reference future. > > Richard Warren > Technical Manager > Website Auditing Limited (Userite) > http://www.userite.com > > -- Ramón Corominas Accessibility specialist Technosite - Fundación ONCE E: rcorominas@technosite.es T: @ramoncorominas P: +34 91 121 0330 W: http://technosite.es
Received on Sunday, 27 July 2014 16:34:19 UTC