W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > August 2014

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

From: Karl Groves <karl@karlgroves.com>
Date: Tue, 12 Aug 2014 20:17:33 -0400
Message-ID: <CABScKPC31BQ5833sg376=dV56xWEc9gaTnf7Q0V7EAiiDgRASg@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Saturday, 14 July 2018 08:23:16 UTC