Re: Your comments on WCAG 2.0 Last Call Working Draft of December, 2007

On Mon, Mar 31, 2008 at 9:37 AM,  <re-clf-nsi@tbs-sct.gc.ca> wrote:
>
>  ==============================================
>
>  A) CONCERNS WITH COMMENT 2 RESPONSE
>
>  Quote from the Comment 2 response:
>  "In WCAG 2.0, we do not require advance warning before opening a window. There are many reasons for this which have been shared with us by blind users. For many people with visual disabilities, some links are better opened to a new window. For instance, if the user is part way through a site which they had to log into, they would have to log in again if they go to a new site in the same window. But if it opened to a new window they would simply close the new window and they are automatically back at the original site without having to log in again. Printer friendly versions are often better it opened to a new window, particularly if the user wants to copy and paste the content elsewhere such as an email. Generally, it is easy to close the new window and the user is returned to the original page where they left off (which will be at the top of any cascade of open windows). Also, assistive technology now announces new windows."
>
>  1) Our recommendation in Comment 2 was to provide advance warning where links open in new windows yet your countering argument is mostly focussed on why it is a good idea to have certain links open in new windows. We were not recommending that opening new windows be banned so we feel that our comments and recommendations were not fully understood.
>
>  Even though we are not against links opening in new windows, we do feel that they are being used too often in scenarios where they are not warranted so it would be very helpful for WCAG 2.0 to provide recommendations on when it is best to open links in new windows and when it is best to instead open links in the current window. With popup blockers being so common, links that open in new windows are frequently being blocked making Web sites that open links in new windows much more difficult to use. It would be very helpful to provide guidance to help limit the opening of new windows to when such behaviour is actually helpful and warranted.
>
>  It is also important to note that many devices do not support links that open in new windows. For instance many Internet-enabled devices (such as phones and handheld devices) do not support links that open in new windows which is another good reason why opening of new windows should be limited to where it is helpful and warranted (and to use approaches that can degrade to opening links in the same window where required).
>
>  RECOMMENDATION: Provide recommendations on when it is best to open links in new windows and when it is best to instead open links in the current window (to help limit the opening of new windows to when such behaviour is actually helpful and warranted). It would also be a good idea to include examples that provide support for user agents that do not support the opening of links in new windows (with at least one example conforming to XHTML 1.0 Strict).

---------------------------------------------
Response from Working Group:
---------------------------------------------
Recommendations would be advisory techniques in our structure.  We
think that your suggestions above is a good idea and have added the
following topic for a future advisory technique.  At this time we do
not have time to get all of the advisory techniques but would be
delighted if you would help us with this one.   There is a form that
you can fill out that will automatically create a new technique.

* Gxxx Opening new windows only when best from accessibility perspective

>
>  -----
>
>  2) We do not agree with your position that advance warning is not required for links that open in new windows. The only justifications you have provided in this response is that "assistive technology now announces new windows" and "The working group felt that assistive technology now gives sufficient warning about opening a new window (if the user clicks on a link and it opens a new window) so that is not covered under any provision including 3.2.5.". This is a very problematic position to take since there is no way of determining whether a new window was "supposed" to open without an advance warning of such behaviour or even how many new windows were "supposed" to open. Your position is very reactive and only works if a new window successfully opens, and only one new window was "supposed" to open. Here are some problems with this approach:
>
>  a) How is a new window notification supposed to be helpful when a new window does not open because it was blocked by a popup blocker? In most cases, assistive technologies will not announce that a new window has been blocked so this creates a very confusing and disorienting scenario since a link will have been activated with seemingly no result. This problem will likely be quite common since most of the JAWS users supported by one of our Adaptive Computer Technology centres have popup blockers installed on their PCs and popup blockers are installed by default as part of Internet Explorer 7 and Firefox installations.
>
>  Advance warnings help to resolve this situation by clearly identifying the expected exceptional behaviour (since links do not open in new windows by default) so both visual and blind users can make the necessary changes to their popup blockers in advance, or at least can easily determine when the expected behaviour did not occur (advance warning of new window + no new window notification = new window did not open successfully).
>
>  b)  How is a user supposed to understand complex scenarios such as a new page opening in the current window while at the same time another page opening in a new window without advance warning being provided? An announcement that a new window has just opened is insufficient information for an assistive technology user to understand such changes. It will likely be quite confusing and disorienting for the user to close the new window that just opened and encounter different content in the original window. Advance warning of this behaviour will make it much easier for a user to understand the resulting behaviour rather than leaving the user to figure out why things seem to be different in the original window even though a new window had opened.
>
>  c) How is a user supposed to determine whether a new window is legitimate or malicious/unsolicited (such as one generated by malware)? Assistive technologies can only identify that a new window has opened but cannot identify whether a new window was "supposed" to open or even how many new windows were "supposed" to open. Advance warning of the expected behaviour will make it easier for the user to determine when unsolicited windows have opened by comparing the number of expected new windows to the number of new windows that actually opened (which is also beneficial in the popup blocker scenario identified earlier).
>
>  d) Without advance warning, there is no easy way to differentiate between links that open in new windows and ones that do not. This can be quite confusing and disorienting for even visual users as there are differences in link behaviour without any way to determine the differences in behaviour in advance. It is much easier for users to deal with a new window opening if there is advance warning that a new window will open. Predictable outcomes are very important to less technical users and users with cognitive impairments (otherwise the outcomes can be jarring and overwhelming) which is why it is important to warn about any changes to the default behaviour of links.
>
>  RECOMMENDATION: Make providing advance warning that a link will open in a new window (or windows) to be programmatically determinable through the link itself (such as including in between <a> or </a> or in the title value for the link) a "AA" requirement. It is important that the warning be part of the link itself since providing the warning elsewhere would not be helpful to users of screen readers that allow them to list all the links on the current page (since surrounding context would not be taken into account).

---------------------------------------------
Response from Working Group:
---------------------------------------------

We have added an advisory technique to SC 3.2.1 (On Focus) and 3.2.2
(On Input) titled, "Giving users advanced warning when opening a new
window."

Note: The provision in WCAG 1.0 (checkpoint 10.1) was incorporated
because, at that time, AT did not warn users when a new window opened
and users found themselves unable to use the back button and wondering
what happened. Today, assistive technologies alert users that new
windows have opened, which lets users know that they should close the
window rather than use the back button. Pop-up blockers that block all
new windows would block new windows for everyone, so some type of
indication is given for most all pop-up blockers to let users know
that something has been blocked, or people with disabilities are at
the same disadvantage as everyone else in that they would not have
access to spawned windows.

>
>  ----------------------------------------------
>
>  Quote from the Comment 2 response:
>  "Q: Why are server-side/instant client-side redirects not a "AA" requirement?
>
>  - because if they are instant - there is no information on the intervening page that is not accessible."
>
>  The response seems to indicate that the redirect portion of Comment 2 was misunderstood. We were asking why "both" server-side/instant client-side redirects are not a "AA" requirement (in comparison to delayed client-side redirects) yet your countering argument is a reason why instant client-side redirects are accessible. We are not contesting the accessibility of instant client-side redirects but are instead arguing that the potential confusion and disorientation related to delayed client-side redirects warrants that it be a "AA" requirement for all redirects to be either server-side or instant client-side.
>

Regarding your question on server-side/instant client-side redirects,
this is covered under Success Criterion 2.2.1 at Level A because
delayed redirects are a type of time limit. The following 3 failures
related to this issue are listed under 2.2.1:

 - F40: Failure of Success Criterion 2.2.1 and 2.2.4 due to using meta
redirect with a time limit
 - F41: Failure of Success Criterion 2.2.1, 2.2.4, and 3.2.5 due to
using meta refresh with a time-out
 - F58: Failure of Success Criterion 2.2.1 due to using server-side
techniques to automatically redirect pages after a time-out

Thanks again for the interest that you have taken in these guidelines.
Could we ask you to let us know whether or not you are satisfied with
this response by Wed, April 16?

Loretta Guarino Reid, WCAG WG Co-Chair
Gregg Vanderheiden, WCAG WG Co-Chair
Michael Cooper, WCAG WG Staff Contact

On behalf of the WCAG Working Group

Received on Friday, 11 April 2008 17:22:45 UTC