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, 11 March 2008 00:19:16 UTC