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

Thank you for reviewing the WCAG 2.0 comments from our accessibility experts and our various working groups and for providing us with a detailed response. We are satisfied with your responses for Comments 1, 4, and 5 but we still have significant concerns with your responses for Comments 2 and 3 as well as a minor concern with the status of Comment 6.

Providing the advisory technique discouraging deprecated features is a good resolution for Comment 4 and a similar approach should be taken for layout tables as they should be considered deprecated as well (CSS-based layouts should be used in favour of table-based layouts just like CSS properties should be used in favour of deprecated features). 

Table-based layouts unnecessarily increase the complexity of the document structure by forcing assistive technology users to repeatedly listen to useless table properties such as the number of columns and rows as well as other table properties which are announced at the beginning of each layout table. 

There is also the problem that table-based layouts frequently nest layout tables within layout tables making the document structure all the more confusing and difficult to understand yet there is nothing in WCAG 2.0 to prevent Web pages from nesting layout tables 5 or more levels deep which would make the document structure confusing and overwhelming even if it somehow makes sense when linearized. There should be an advisory technique at the very least dealing with multiple levels of nested tables.

RECOMMENDATION: Including technique G146 in success criterion 1.4.4 as well as providing recommendations in techniques F46 and F49 is helpful but it would be very beneficial to have an advisory technique that specifically recommends CSS-based layouts over table-based layouts and provides a strong rationale for such a recommendation (G146 only deals with building a layout that handles scalable text so is not sufficient). There should also be an advisory technique (at a minimum) that recommends limits on the nesting of layout tables. Such advisory techniques would help to prevent layouts from becoming confusing and overwhelming and would also help to encourage the adoption of CSS-based layouts which are much easier to maintain (only have to change a few files to update the layout of an entire site) and are much less cumbersome to navigate for assistive technology users.

==============================================

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

-----

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

----------------------------------------------

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.

==============================================

B) CONCERNS WITH COMMENT 3 RESPONSE

Quote from the Comment 3 response:
"The situations you describe are addressed differently in WCAG 2.0 than in 1.0. WCAG 2.0 has an improved set of conformance requirements. Refer to http://www.w3.org/TR/WCAG20/#conformance-reqs. We believe this is a more effective and thorough approach."

The problem is that the conformance requirements do not cover a technology being disabled or unavailable resulting in accessibility issues, it only covers whether a technology is "accessibility-supported" or not which only deals with compatibility with assistive technologies. 

a)	What about users with cell phones and other Internet-enabled devices? The way things are worded now, you could make JavaScript rendered content that is fully accessible to assistive technologies and keyboard users yet unavailable when JavaScript is disabled and the page could still achieve full compliance. 

b)	What if the device does not support the required plugin (such as Flash)? There could be an accessibility supported plugin that is available for normal browsers but are not available for certain devices resulting in Web pages. This would meet the conformance requirements but still result in content being unavailable to certain users. 

Ultimately the conformance requirements as they are worded now leave many loopholes where sites can be completely inaccessible and unusable on certain user agents yet still be fully compliant (such as a fully JavaScript-rendered site that is fully accessible to assistive technologies but just an empty page on a handheld device that does not support JavaScript or secure environments where JavaScript is disabled).

RECOMMENDATION: Either expand "Accessibility-Supported Technologies" conformance requirement to cover the case where an accessibility-supported technology is disabled or the required accessibility-plugin is not supported by the widely distributed user agent (cell phones and Internet-enabled devices are pretty common but most do not support Flash or JavaScript).

==============================================

C) CONCERN WITH COMMENT 6 STATUS

For Comment 6, the status indicates "VERIFIED / NOT ACCEPTED" yet you have indicated that you will use "HTML and XHTML" which is consistent with the proposed change of "Provide XHTML in addition to HTML for any instances where HTML is used." Shouldn't the status be changed to "VERIFIED / ACCEPTED" or at the very least "VERIFIED / PARTIAL/OTHER"?


Common Look and Feel Office | Bureau de la normalisation des sites Internet
Treasury Board of Canada, Secretariat | Secrétariat du Conseil du Trésor du Canada
Government of Canada | Gouvernement du Canada






-----Original Message-----
From: Loretta Guarino Reid
Sent: March 10, 2008 8:19 PM
To: Common Look and Feel/Normalisation des sites Internet
Cc: public-comments-WCAG20@w3.org
Subject: Your comments on WCAG 2.0 Last Call Working Draft of December, 2007

Dear CLF Canada,

Thank you for your comments on the 11 Dec 2007 Last Call Working Draft
of the Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2007/WD-WCAG20-20071211). The WCAG Working Group
has reviewed all comments received on the December draft. Before we
proceed to implementation, we would like to know whether we have
understood your comments correctly and whether you are satisfied with
our resolutions.

Please review our resolutions for the following comments, and reply to
us by 31 March 2008 at public-comments-wcag20@w3.org to say whether
you accept them or to discuss additional concerns you have with our
response. Note that this list is publicly archived.

Please see below for the text of comments that you submitted and our
resolutions to your comments. Each comment includes a link to the
archived copy of your original comment on
http://lists.w3.org/Archives/Public/public-comments-wcag20/, and may
also include links to the relevant changes in the WCAG 2.0 Editor's
Draft of 10 March 2008 at
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20080310/.

Note that if you still strongly disagree with our resolution on an issue,
you have the opportunity to file a formal objection (according to
3.3.2 of the W3C Process, at
http://www.w3.org/2005/10/Process-20051014/policies.html#WGArchiveMinorityViews)
to public-comments-wcag20@w3.org. Formal objections will be reviewed
during the candidate recommendation transition meeting with the W3C
Director, unless we can come to agreement with you on a resolution in
advance of the meeting.

Thank you for your time reviewing and sending comments. Though we
cannot always do exactly what each commenter requests, all of the
comments are valuable to the development of WCAG 2.0.


Regards,

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

----------------------------------------------------------
Comment 1: Space missing in "visuallycustomized" of the "Customizable"
list item.
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0026.html
(Issue ID: 2404)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

Change "visuallycustomized" to "visually customized" in the
"Customizable" list item.

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

Thank you, we have fixed this.

----------------------------------------------------------
Comment 2: Potential consequences of success criterion 3.2.5 are too
severe for "AAA"
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0027.html
(Issue ID: 2405)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

This success criterion should be increased to "AA" or at least should
be split into two different success criterions with one being "AA" and
the other being "AAA".

If the end result of some of the situations identified in the success
criterion is user disorientation due to unexpected changes in context
then the potential consequences are too severe for a "AAA" success
criterion.

For instance, why is there no "AA" or higher success criterion that
requires links that open in new windows to have advanced warning that
is both visible and can be programmatically determined? Why are
server-side/instant client-side redirects not a "AA" requirement? Why
are 3.2.1 (On Focus) and 3.2.2 (On Input) "A" level success criterions
yet the two aforementioned situations are only "AAA"?

Proposed Change:
1) Change success criterion 3.2.5 from "AAA" to "AA".

or

2) Split success criterion 3.2.5 into two separate "AA" and "AAA"
success criterions with the "AA" success criterion covering the more
important situations such as links that open in new windows and
server-side/instance client-side redirects and the "AAA" success
criterion covering the less important situations.

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

Most of what you are addressing in 3.2.5 is now addressed in 3.2.1 and
3.2.2 both of which are at level A.

3.2.1 On Focus: When any component receives focus, it does not
initiate a change of context. (Level A)

3.2.2 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. (Level A)

Success Criteria 3.2.5 is an omnibus item and also builds on 3.2.2 by
removing the "advance warning" exception that is in 3.2.2. Therefore,
forbidding a change of context on focus. We should note that a change
of context on focus and a change of context on activation are
distinct. 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.

Some other notes in answer to your questions:

Q: For instance, why is there no "AA" or higher success criterion that
requires links that open in new windows to have advanced warning that
is both visible and can be programmatically determined?

- Anything that conveys information or has function needs to be
programmatically determinable, so we don't specify that again here.

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

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.

Q: Why are 3.2.1 (On Focus) and 3.2.2 (On Input) "A" level success
criteria yet the two aforementioned situations are only "AAA"?

- See above. The aforementioned situations are covered at A or not at all.

In discussions with screen reader users, we found that it is often
preferred that a link opens to a new window than to stay in the
current window. For instance, if a screen reader user has to log into
a site, and a there is a link to something outside of the site, it is
better that that link opens to a new window because otherwise they
would have to log in again on returning. In general, if a new window
opens when a link is clicked, it is easy to return to the original
page, in its current state by simply closing the new window. This
returns the user to where they were before, with the page in the state
that it was in before they left it. In a web environment that is
moving more and more towards application based interaction,
maintaining the current state of the page is much more important that
it was when WCAG 1.0 came out.

----------------------------------------------------------
Comment 3: Absence of a success criterion that covers the absence of
support for scripting or programmatic objects
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0028.html
(Issue ID: 2406)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

Why is there nothing in 4.1 regarding the absence of support for
scripting or programmatic objects? Unlike WCAG 1.0, WCAG 2.0 does not
cover situations such as:

a) Navigation elements and controls that are still available but do
not work properly when scripting/programmatic objects not supported
such as onChange event handler on a select element or JavaScript
controlled links (with onClick event handler and href="#" or even
href="javascript:...").

b) Critical information that is only displayed when
scripting/programmatic objects are supported.

c) Forms without an action that only submit when
scripting/programmatic objects are supported

d) Field validation that only works when scripting/programmatic
objects are supported

Absence of a success criteria requirement that deals with diminished
scripting/programmatic objects support will decrease potential support
for user agents where scripting/programmatic object support may be
limited such as:

a) Machines with high security requirements where
scripting/programmatic object support is intentionally limited due to
security requirements (such as high security workplaces and some
public computers)

b) User agent limitations (older browsers, specialized adaptive
technology platforms, internet enabled devices such as PDAs and cell
phones).

There should be a requirement to hide/not display all elements that do
not function properly when scripting/programmatic objects are disabled
and to provide alternative means of accessing critical information
and/or functionality when scripting/programmatic object support is
absent (possible exception for security functionality that can't be
provided without scripting/programmatic objects).

Proposed Change:
Add a success criterion ("A" or "AA") that covers the absence of
support for scripting or programmatic objects.

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

The situations you describe are addressed differently in WCAG 2.0 than
in 1.0. WCAG 2.0 has an improved set of conformance requirements.
Refer to http://www.w3.org/TR/WCAG20/#conformance-reqs. We believe
this is a more effective and thorough approach.

For example, the requirements ensure that any technology, (i.e.,
JavaScript) that is used (even if not relied upon for conformance)
must conform to certain guidelines, including the success criteria
that address keyboard access and keyboard traps.  And any technology
that is relied upon for conformance (whether it be Javascript or any
other technology) must be accessibility supported by widely available
assistive technologies. If for example, a Javascript menu is used that
does not work with a screen reader in the environment, or it is a menu
that is not keyboard operable, then in order for the page to conform,
there would have to be a fallback menu that does work with a screen
reader and is keyboard operable (as per Conformance Requirement 4).

Regarding your suggestion to hide/not display elements that do not
function when technologies are turned off, we think it is a good idea
and have added an advisory technique titled, "Not displaying content
that relies on technologies that are not accessibility-supported when
the technology is turned off or not supported."


----------------------------------------------------------
Comment 4: Absence of success criterion for deprecated and obsolete features
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0029.html
(Issue ID: 2407)
Status: VERIFIED / NOT ACCEPTED
----------------------------
Original Comment:
----------------------------

Why is there no success criterion (not even a "AAA") that requires
deprecated and obsolete features to be avoided? For instance, obsolete
features in Java are generally not compatible with the Java
Accessibility Bridge which would result in significantly decreased
compatibility with screen readers. Same for deprecated features in
HTML/XHTML which can also result in decreased accessibility (such as
limiting the ability of users to configure a Web page to meet their
accessibility needs).

Proposed Change:
Add a success criterion that covers deprecated and obsolete features.

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

Because not all deprecated features of a given technology present an
accessibility barrier, the requirement to avoid them has been removed
from the WCAG 2.0 requirements. Where deprecated features do present
barriers, we have described them as failures (ex. F47: Failure of
Success Criterion 2.2.2 due to using the blink element).

Since it's still a good idea to avoid the use of deprecated features,
we have added an advisory technique to Guideline 4.1 that reads,
"Avoiding deprecated features of W3C technologies."

----------------------------------------------------------
Comment 5: Absence of success criterion for markup/properties that
prevent configuring pages/interfaces to meet accessibility needs
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0030.html
(Issue ID: 2408)
Status: VERIFIED / NOT ACCEPTED
----------------------------
Original Comment:
----------------------------

Why is there no success criterion that deals with markup/properties
that prevent users from configuring pages/interfaces to meet their
accessibility needs?

Many languages have the ability to lock down interfaces/visual design
(such "!important" in CSS) and doing so can have a negative impact on
the level of accessibility for users who need to configure the
page/interface to meet their accessibility needs (such as users that
need to change the colour scheme in order to visually perceive the
information).

Proposed Change:
Add success criterion that deals with markup/properties that prevent
users from configuring pages/interfaces to meet their accessibility
needs

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

In general, WCAG 2.0 addresses these concerns by including
requirements that ensure that it is possible for a user to achieve a
given result. For example, Success Criterion 1.4.2 requires that a
mechanism is available to pause or stop audio. In some cases, a
mechanism may be explicitly provided in the content. In others, it may
be relied on to be provided by either the platform or by user agents,
including assistive technologies.

Also, the ability for users to override !important rules in CSS is a
User Agent Issue. (Refer to UAAG Guideline 4
http://www.w3.org/TR/WAI-USERAGENT/guidelines.html#gl-user-control-styles)

----------------------------------------------------------
Comment 6: Absence of mention of XHTML whenever HTML is used for
referring to Web page markup
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0031.html
(Issue ID: 2409)
Status: VERIFIED / NOT ACCEPTED
----------------------------
Original Comment:
----------------------------

XHTML should be receiving the same level of visibility as HTML but it
is noticeably absent  whenever HTML is used for referring to Web page
markup.

Proposed Change:
Provide XHTML in addition to HTML for any instances where HTML is
used. For instance "XHTML/HTML", "(X)HTML", "XHTML and HTML" could be
used.

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

Those using HTML may not know that (X)HTML is used to refer to both
XHTML and HTML. We will use "HTML and XHTML" in places where
techniques apply to both.

Received on Tuesday, 1 April 2008 15:23:58 UTC