Your comments on WCAG 2.0 Last Call Draft of April 2006

Dear Robert Whittaker ,

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

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

The baseline concept is not wery well explained in the guidelines, and
is never really defined properly. External docuemnts should not be
relied upon to define key conepts.

Also, the descriptive use of \"technologies\" without further
explanation is not good when you\'re really refering to data formats,
markup and scripting languages (rather than software).

Proposed Change:

Provide a clearer definition / explanation of the baseline concept in
the guidelines themselves.

Provide at least one example of a baseline specification (perhaps with
the examples under the \"Who sets baselines?\" heading).

Response from Working Group:

The conformance section of WCAG2 has been completely rewritten. The
term "baseline" has been replaced by "accessibility-supported Web
technologies". The issue of what it means to be an
accessibility-supported Web technology is addressed in the section
"Accessibility Support of Web Technologies" at .

Comment 2:

(Issue ID: LC-808)

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

The terminology for \"authored unit\", \"authored component\", \"web
unit\" seems rather excessive, and potentially confusing. Can it be
simplified with fewer (and perhaps more natural) terms?

Proposed Change:

Response from Working Group:

We have replaced the term "Web unit" with "Web page" and have
reformulated the success criteria and glossary to remove both
"authored unit" and "authored component" from the guidelines.

Comment 3:

(Issue ID: LC-809)

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

The definition of "parsed unambiguously" is rather ambiguous, and the
gudelines themselves don't explain what is required. Does this mean a
particular UA must have the same structure on each parsing of the same
page (which only requires that UA behave deterministically) or that
*all* UAs get the same structure (which is impossible without having
all UAs store their data in the same way)?

For accessibility, it is vital that data be presented in a manner that
complies with a published standard - otherwise how do UA-makers, or
people who want/need to write their own parsing tools know what to
expect and how to handle the data. With a multiplicity of UAs, the
only sensible interpretation of "parsed unambiguously" is that the
data stream complies with a published standard. That being the case,
the guidelines should state this.

Proposed Change:

Simplify and strengthen the guidelines by removing the concept of
"parsed unambiguously", and replace it with a guideline that says that
data formats used must comply with a published specification (to be
referenced in the baseline).

(Of course this may be an author-published one - though authors should
be discouraged from doing so.)

Response from Working Group:

To make this requirement easier to understand, we have reworded SC
4.1.1 as follows:

Content implemented using markup languages has elements with complete
start and end tags, except as allowed by their specifications, and are
nested according to their specifications.

Note: Start and end tags that are missing a critical character in
their formation, such as a closing angle bracket or a mismatched
attribute value quote are not complete.

The working group looked at this topic carefully over an extended
period of time and concluded that requiring strict adherence to all
aspects of specifications does not necessarily result in an increase
in accessibility. For example, it is possible to create invalid pages
that present no accessibility barriers. It is also possible in certain
situations to enhance accessibility through the use of markup that is
not part of the specification.

The working group must work within its charter and only include things
that directly affected accessibility. Some aspects of "use
technologies according to specification" and validity do relate to
accessibility. However, others do not. So requiring validity would
take us beyond our charter. We do recommend it though and it is our #1
technique listed for conforming to SC 4.1.1.

Received on Thursday, 17 May 2007 23:43:18 UTC