- From: Karl Groves <karl@karlgroves.com>
- Date: Tue, 12 Aug 2014 20:17:33 -0400
- To: Andrew Kirkpatrick <akirkpat@adobe.com>
- Cc: "public-comments-wcag20@w3.org" <public-comments-wcag20@w3.org>
Thank you for the kind response and clarification, WCAG WG Members! On Tue, Aug 12, 2014 at 7:39 PM, <akirkpat@adobe.com> wrote: > Dear Karl Groves , > > The Web Content Accessibility Guidelines Working Group has reviewed the > comments you sent [1] on the Last Call Working Draft [2] of the Techniques > for WCAG 2.0 (Public Review Draft) published on 24 Jul 2014. Thank you for > having taken the time to review the document and to send us comments! > > The Working Group's response to your comment is included below. > > Please review it carefully and let us know by email at > public-comments-wcag20@w3.org if you agree with it or not before 19 August > 2014. In case of disagreement, you are requested to provide a specific > solution for or a path to a consensus with the Working Group. If such a > consensus cannot be achieved, you will be given the opportunity to raise a > formal objection which will then be reviewed by the Director during the > transition of this document to the next stage in the W3C Recommendation > Track. > > Thanks, > > For the Web Content Accessibility Guidelines Working Group, > Michael Cooper > W3C Staff Contact > > 1. > http://www.w3.org/mid/CABScKPDiOxHwLKBiMP8+kzwDu9U72=50jqkFaM4hts2=tq5BjQ@mail.gmail.com > 2. http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/ > > > ===== > > Your comment on G201: Giving users advanced warning when opening a new > window: >> Before my specific comments/ questions I'll provide the following >> background information: >> >> WCAG 2.0 SC 3.2.2 says: "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." >> >> According to WCAG2.0 documentation, change of context specifically >> includes >> opening new windows[1]. "Example: Opening a new window, moving focus to >> a >> different component, going to a new page (including anything that would >> look to a user as if they had moved to a new page) or significantly >> re-arranging the content of a page are examples of changes of context." >> >> A user interface component is defined as "a part of the content that is >> perceived by users as a single control for a distinct function"[2] >> >> The WCAG documentation for Understanding SC 3.2.2[3] provides a note >> saying >> "Note: This Success Criterion covers changes in context due to changing >> the >> setting of a control. Clicking on links or tabs in a tab control is >> activating the control, not changing the setting of that control." >> >> And yet WCAC Advisory Technique G201 is titled "Giving users advanced >> warning when opening a new window", and demonstrates two approaches for >> providing this warning on a link.[4] and this technique is listed with/ >> associated to informative information regarding 3.2.2 >> >> Similar techniques include H83, SCR24, and G200. In all cases, the >> technique discusses the disorientation caused by changing context >> unpredictably. However, there are no failure techniques listed for >> *not* >> declaring that a new window is opened by a link. >> >> A nearly identical discussion on this topic took place earlier this >> summer >> on the WAI-IG list[5]. Of particular note is Gregg Vanderheiden's >> thorough >> response in that thread. >> >> The general takeaway from the comments in that thread - particularly >> Gregg >> and David's messages - is that opening new windows, with or without >> warnings, is *not* a violation of 3.2.2. >> >> Among the reasons for this not being a failure of 3.2.2 are the >> following: >> "Opening a new window is something that can easily be - and is for many >> AT >> is - detected, and the user notified.", and >> "But clicking on a link very commonly changes the context" >> >> The messages posted in that thread by Gregg and David are very good at >> explaining the reasoning for *not* including opening links in new >> windows >> as a failure. Gregg also makes an excellent point that "AT failures are >> not >> Failures [when it comes to] the working group documents. " >> >> >> Given the above, here are my comments: >> >> First, a general response to the reasons provided by Gregg and David: >> The detection provided by ATs (specifically screen readers) occurs >> *after* >> the new window has been opened. This is not a warning before the fact, >> as >> required by 3.2.2: "unless the user has been advised of the behavior >> before >> using the component." Additionally, the practical reality is that only >> screen readers do this detection. No mechanism exists in any other type >> of >> AT or in any user agent and therefore this comment applies only to >> screen >> reader users, apparently ignoring the fact that other types of people >> are >> impacted by inaccessible systems and other types of people would need >> this >> feature. >> >> The statement that "clicking on a link very commonly changes the >> context" >> ignores the many arguments provided within the G201 technique document >> regarding the disorientation. While it is true that it is the nature of >> navigation to change the current context, the context change that >> occurs >> when opening a new window is more likely to disorient the user and this >> fact is acknowledged in WCAG's own informative documentation. >> Effectively, >> the context change is more drastic and, without the notification, more >> likely to disorient. The user understands and expects a link to change >> the >> current context within the current window/ tab. They do not/ should not >> have to assume that a new window will open, too. This is not the >> defined >> behavior of a link. >> >> >> Here are my specific comments regarding WCAG WG information: >> >> In WCAG SC 3.2.2, the phrase "changing the setting" is very specific >> and >> very clearly different from "activating" a control, which is the action >> taken upon links. The association of G201, despite being an Advisory >> Technique, contradicts the notion that links are not covered by 3.2.2 >> and >> only serves to confuse the reader. >> >> If the WG intends to maintain that 3.2.2 does not apply to links, the >> association of G201 within informative information of "Understanding >> 3.2.2" >> should be removed and, if anything, associating it with 3.2.5. However >> based on the information provided it doesn't appear that opening links >> in >> new windows with the target attribute has anything to do with 3.2.2 or >> 3.2.5 >> >> Additionally, the "Understanding" doc contains the following note: >> Note: This Success Criterion covers changes in context due to changing >> the >> setting of a control. Clicking on links or tabs in a tab control is >> activating the control, not changing the setting of that control. >> >> I'd recommend appending more definitively worded sentence to the end of >> that note, changing the note to read: >> Note: This Success Criterion covers changes in context due to changing >> the >> setting of a control. Clicking on links or tabs in a tab control is >> activating the control, not changing the setting of that control. >> *Opening >> a link in a new window or tab is not a failure of this success >> criteria.* >> >> >> TL;DR: If opening links in new windows doesn't apply to 3.2.2 then >> eliminate G201 and explicitly say so in 3.2.2's "Understanding" doc. >> >> Thanks >> >> >> 1 - http://www.w3.org/TR/2008/REC-WCAG20-20081211/#context-changedef >> 2 - >> > http://www.w3.org/TR/2008/REC-WCAG20-20081211/#user-interface-componentdef >> 3 - >> > http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-unpredictable-change.html >> 4 - http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140408/G201 >> 5 - >> > http://lists.w3.org/Archives/Public/w3c-wai-gl/2014JulSep/thread.html#msg14 > > > Working Group Resolution (LC-2946): > Success Criterion 3.2.2 does not require that users be notified in advance > when a link will open a new window. > > SC 3.2.2 reads: 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. > > It is accurate to say that WCAG 2.0 regards links as a type of user > interface component, however the WCAG working group does not consider > following a link to be equivalent to changing the setting of that > component. If a user were to change the selected item in a HTML select > control, list box, or radio group and that change were to result in a > change of context for the user, that would represent a failure under 3.2.2, > but merely following a link does not. > > Failure technique F37 addresses situations with select/list/radios and SC > 3.2.2: http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140408/F37 > > To make this more clear, the working group is making a series of changes to > the supporting documents: > 1) G200 - This general technique refers to the use of links or buttons on > web pages that change the user's context when clicked on. The technique > currently references 3.2.1 (on focus) and 3.2.5 (change on request). The > technique will be modified to refer only to the 3.2 Guideline as an > advisory technique. > 2) G201 - This general technique suggests providing a warning to users > prior to their clicking on a link. This technique will be marked as an > advisory technique for guideline 3.2. > 3) F37 - This technique ("Failure of Success Criterion 3.2.2 due to > launching a new window without prior warning when the status of a radio > button, check box or select list is changed") will be adjusted to use the > term "selection" instead of "status" to more accurately reflect what is > changing. "Status" is ambiguous. > 4) Understanding 3.3.2 > (http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-unpredictable-change.html). > Change the text > "Changing the setting of any user interface component is changing some > state in the control that will persist when the user is no longer > interacting with it. So checking a checkbox or entering text into a text > field changes its setting, but activating a link or a button does not. " > to > "Changing the setting of any user interface component is changing some > aspect of the control in a way that will persist when the user is no longer > interacting with it. For example, checking a checkbox, entering text into a > text field, or changing the selected option in a list control changes its > setting, but activating a link or a button does not." > > > > > > > > ---- > > -- Karl Groves www.karlgroves.com @karlgroves http://www.linkedin.com/in/karlgroves Phone: +1 410.541.6829 Modern Web Toolsets and Accessibility https://www.youtube.com/watch?v=_uq6Db47-Ks www.tenon.io
Received on Wednesday, 13 August 2014 00:18:22 UTC