Re: Comments re: Links opening new windows ( LC-2946)

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







----

Received on Tuesday, 12 August 2014 23:39:58 UTC