Your comments on WCAG 2.0 Last Call Draft of April 2006

Dear Alex Li ,

Thank you for your comments on the 2006 Last Call Working Draft of the
Web Content Accessibility Guidelines 2.0 (WCAG 2.0 We appreciate the
interest that you have taken in these guidelines.

We apologize for the delay in getting back to you. We received many
constructive comments, and sometimes addressing one issue would cause
us to revise wording covered by an earlier issue. We therefore waited
until all comments had been addressed before responding to commenters.

This message contains the comments you submitted and the resolutions
to your comments. Each comment includes a link to the archived copy of
your original comment on, and may
also include links to the relevant changes in the updated WCAG 2.0
Public Working Draft at

PLEASE REVIEW the decisions  for the following comments and reply to
us by 7 June at to say whether you are
satisfied with the decision taken. Note that this list is publicly

We also welcome your comments on the rest of the updated WCAG 2.0
Public Working Draft by 29 June 2007. We have revised the guidelines
and the accompanying documents substantially. A detailed summary of
issues, revisions, and rationales for changes is at . Please see for more information about the current review.

Thank you,

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:

(Issue ID: LC-507)

Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):

This is related to user-entered or contributed content.  It was
brought to discussion on May 4th WCAG con call already with no
conclusion. Due to the fact that you can violate WCAG with an ASCII
smily face (1.1.1) or change of language without proper tag, or use of
jargon, any user input can potentially violate WCAG. If the user input
resurface, even as input confirmation, the web unit would
automatically fail WCAG. All seach engines would fail because it
cannot stop users from typing in an ASCII smily in the search box. The
subsequent search result screen of finding x number, even if it is 0,
of hits with the smily would fail. This is the same with foreign
languages and jargon. All websites containing logon screen would fail
because user can type in a smily face into the user id box, whether
such user id exist or not. The system returns to confirm the id. The
web unit of the confirmation just failed WCAG. All webmails would fail
because incoming mails could come from a plain text mail client or
contain inaccessible mail content of all sorts. Webmail cannot alter
the content of incoming email without violation of privacy, at the
minimum. No webmail can claim conformity. All photosites would fail
because user can always put in empty or inproper alt tag of photos
that they submit. All blogs would fail because user input is
essential. Product user reviews, such as those in Amazon or Cnet,
would fail.

The list can go on and extend to all web applications. As soon as a
user agent accepts user input that are not restricted (anything other
than dropdown list or radio button), they cannot conform. In fact,
comment area of WCAG 2.0 last call fails because you cannot stop me
from typing in jargon, foreign language, or ascii art. I'm making this
violation at the botton of the mail just to make a point. Scoping out
user-entered content is extremely difficult for many sites, especially
when user-entered content is pervasive. How would a blog, web mail,
evite, business application scope out user-entered content? Such
information is essentially on every web unit.

wie Sie den Test führen können

Proposed Change:

Add a paragraph in the comformance area that user-contributed content
is automatically scoped out.

Response from Working Group:

We have rewritten the conformance section to clarify that WCAG is
descriptive rather than prescriptive.  That is, it doesn't say what
should be accessible. Rather, it is a measure of accessibility.  The
conformance section has been rewritten to reflect this.

A way to specify partial conformance was also added. See

We have clarified the situation by removing all exceptions and adding
the following at the end of the conformance section:

Note: If pages can not conform (for example, conformance test pages or
example pages) they would not be included in the conformance claim.

Comment 2:

(Issue ID: LC-556)

Part of Item: Related Resources
Comment Type: TE
Comment (including rationale for proposed change):

Should consider adding the following reference in the related resources area.

Proposed Change:

Should consider adding the following reference in the related resources area.

Response from Working Group:

The working Group agrees and has added to the Related Resources section of
"How to Meet SC 1.1.1".

Comment 3:

(Issue ID: LC-561)

Part of Item: Intent
Comment Type: TE
Comment (including rationale for proposed change):

May want to add advisory technique to skip over non-baseline content.

Proposed Change:

Add the optional/advisory techniques to skip over non-baseline content.

Response from Working Group:

We have added an advisory technique "Providing a mechanism to skip
non-accessibility-supported content" to Conformance Requirement 6.

Comment 4:

(Issue ID: LC-717)

Part of Item: Examples
Comment Type: GE
Comment (including rationale for proposed change):

It is not clear from the success criteria that greyed-out inactive
element would pass 1.3.2.

Proposed Change:

Add simple example that grey-out inactive elements are visually
distinguishable from normal active elements.

Response from Working Group:

We have added an example of disabled form elements to How To Meet
Success Criterion 1.3.2.

Comment 5:

(Issue ID: LC-836)

Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):

Requiring alternative version from the same URI would not be logical
if the content in question is part of the process.  In other words,
you normally would not switch to alternative version or text-only
version in the middle of a check-out process.  You normally do it at
the beginning of the process that lead to throught the original or
alternative version.

Proposed Change:

Add \"except if the content is part of a process and that alternative
version selection can be made by the user at the beginning of the
process.\" to 4.2.1.  Yes, I know this is longwinded.  It is not a
live or die problem.  But it would make logical sense.

Response from Working Group:

We have moved discussion of alternate versions of content to the
Conformance section of the Guidelines, and we have clarified by adding
the following conformance criterion:
"Alternate Versions: If the Web page does not meet all of the success
criteria for a specified level, then a mechanism to obtain an
alternate version that meets all of the success criteria can be
derived from the nonconforming content or its URI, and that mechanism
meets all success criteria for the specified level of conformance. The
alternate version does not need to be matched page for page with the
original (e.g. the alternative to a page may consist of multiple
pages). If multiple language versions are available, then conforming
versions are required for each language offered.

This still does not permit a many-to-many matching, as separate
processes would imply.

Received on Thursday, 17 May 2007 23:26:33 UTC