W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > November 2007

Your comments on WCAG 2.0 Public Working Draft of May, 2007

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Sat, 3 Nov 2007 21:45:24 -0700
Message-ID: <824e742c0711032145k21af43c8l293c52aa204fdba2@mail.gmail.com>
To: "Jean-Marie D'Amour" <jmdamour@accessibiliteweb.com>
Cc: public-comments-WCAG20@w3.org

Dear Jean-Marie D'Amour,

Thank you for your comments on the 17 May 2007 Public Working Draft of
the Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2007/WD-WCAG20-20070517/). The WCAG Working Group
has reviewed all comments received on the May draft, and will be
publishing an updated Public Working Draft shortly. Before we do that,
we would like to know whether we have understood your comments
correctly, and also whether you are satisfied with our resolutions.

Please review our resolutions for the following comments, and reply to
us by 19 November 2007 at public-comments-wcag20@w3.org to say whether
you are satisfied. Note that this list is publicly archived. Note also
that we are not asking for new issues, nor for an updated review of
the entire document at this time.

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 May-October 2007 at

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.


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: H1-H6, Leval A or AAA?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0218.html
(Issue ID: 2060)
Original Comment:

Sufficient Techniques for 1.3.1 (Level A) mentioned: H42: Using h1-h6
to identify headings.

Sufficient Techniques for 2.4.9 (Level AAA) mentioned: G141:
Organizing a page using headings and more specifically: In HTML, this
would be done using the HTML heading elements (h1, h2, h3, h4, h5, and

It is confusing that a level A and a level AAA refer to the same technique.

Proposed Change:
Withdraw of G141 in reference with 2.4.9 in order to make clear that
structuring pages with h1-h6 is a level A requirement.

Response from Working Group:

SC 1.3.1 says that if the Web page contains headings, they are marked
up in a way that AT can recognize them. That is, in HTML, they are
marked up with heading tags, rather than just being styles visually as
headings. However, it is entirely up to the author whether or not to
includes headings in the content.

SC 2.4.9 says that headings are used to identify sections of the Web
page. An author may need to add headings to satisfy this success
criterion. Of course, if he adds headings, they must still satisfy SC
1.3.1, which means that they must be marked up properly.

"G141: Organizing a page using headings" is a general technique
describe how to use headings to organize content.

Comment 2: SC 2.4.8: Level of priority
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0219.html
(Issue ID: 2061)
Original Comment:

The purpose of each link can be identified from the link text. This is
important for ease of use by screenreader users because no
screenreader can easily read the context of the link as proposed by
level A criterion.

Proposed Change:
Level AA.

Response from Working Group:

The working group recognizes that the link list mechanism provided by
user agents and assistive technology will provide best results when SC
2.4.8 is satisfied.

While the working group encourages authors to make link text as
descriptive as possible out of context, we do not feel that this
success criterion can be satisfied for all Web pages. For Example:
- a page has book titles followed by PDF, HTML, DOC.
- Article name (long) followed by a sentence and the link "more"
- GOOGLE search where each entry has text plus the following links
[translate this page] HTML and [CACHED] and [SIMILAR PAGES]
- toolbar with menus with an arrow icon - the link says "open".
Having full links makes the page very cluttered, harder cognitively to
find things  when the same long (sometimes multi-line) text is
repeated with one word different, and is very long to listen to for
those not adept at auditory skipping (or where unique information is
back end loaded)

These issues were considered carefully for a long time, the working
group feels that having 2.4.4 at Level A and this issue addressed at
Level AAA strikes the right balance.

While user agent and assistive technology support for finding the link
context is poorer than we would like, we have checked that there is at
least one case of support for each of the types of link context we
have listed as sufficient techniques. So a user who has tabbed to a
link can ask for those pieces of context without leaving the link.

We hope that if authors satisfy SC 2.4.4 and make link context
programmatically determinable, user agent developers will find a way
to let users access the context when needed, such as when the link
list is created.

The first techniques listed in 2.4.4 are:
"G91: Providing link text that describes the purpose of a link
H30: Providing link text that describes the purpose of a link for
anchor elements (HTML)

Comment 3: SC 4.1.1: Automatic testing
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0220.html
(Issue ID: 2062)
Original Comment:

4.1.1 Parsing: 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.
(Level A)

I agree only if we have a tool to test it automatically.

Proposed Change:
Be sure that we have a tool to test it automatically.

Response from Working Group:

A specific tool to test this success criterion is definitely
desirable, and vendors and toolmakers should be encouraged to produce
such tools. However, the success criterion can be tested by using most
any validator and then looking at the errors it identifies to see if
any of these are listed.

For example, any XML parser can perform these checks for XML-based
content. In fact, this is already a requirement for conforming XML
parsers: "Non-validating processors are REQUIRED to check only the
document entity, including the entire internal DTD subset, for
well-formedness." (refer to http://www.w3.org/TR/REC-xml/#proc-types).
For HTML, a validator would also catch these issues, but the evaluator
would need to manually check the syntax for elements that are not
allowed by the specification.
Received on Sunday, 4 November 2007 04:45:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:14:45 UTC