LC-2946
Karl Groves <karl@karlgroves.com> (archived comment) |
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
|
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." |
tocheck |
|---|