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 22:09:55 -0700
Message-ID: <824e742c0711032209w408448e5v537fca4535ce0404@mail.gmail.com>
To: "Sailesh Panchang" <spanchang02@yahoo.com>
Cc: public-comments-WCAG20@w3.org

Dear Sailesh Panchang,

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: Problem with H39 Description
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Feb/0000.html
(Issue ID: 1925)
Original Comment:

Refer: HTML techniques #H39 - Description

Problem text :
"The objective of this technique is to identify data tables using the
caption element. The caption is shown on the screen and reported by screen
This technique may be a good choice when tables are difficult to identify,
for example, when text immediately preceding the table does not refer
directly to the table, or when there are multiple tables in the same Web
The caption element is similar to a heading. Unlike a heading element
(h1-h6), however, the caption element is part of the table itself.
Therefore, using caption ensures that information identifying the table is
always kept with the table."

Comment type: Description is too verbose and  imprecise. Caption is a table
identifier and is useful regardless of whether there is one or more tables
on a page.  In the absence of captions too one can navigate to different
tables as well as identify them distinctly using a screen reader. A caption
can also be marked up with an h<n> tag.

Proposed: The caption for a table is a table identifier  and is like  a
title or heading for the table. A caption is the appropriate markup for such
text and it ensures that the table identifier appears along with the table.
Screen reading software allows one to navigate directly to the caption for a
table if one is present.

Response from Working Group:

We have rewritten the description section of H39 to address your concerns.

Comment 2: The use of SCOPE for a simple table in cells that use is futile
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Feb/0001.html
(Issue ID: 1927)
Original Comment:

Refer: Example 1 under H63 HTML Techniques in Techniques for WCAG 2.0
i. The use of SCOPE for a simple table in cells that use <TH> is futile. In
fact if TD is used then SCOPE should be used for such a simple table. Some
screen readers that do not support SCOPE do not read any headers as they are
programmed to do for simple tables. So I would not recommend this example.
ii. The statement ' Following the HTML 4.01 specification, it is marked
as a td element because it is both a data cell and a header cell.', too is
unnecessary in the light of the text proposed above under description. Also
it is not the objective of this document to educate the reader about the
HTML specs.

Include an example with column#1 containing serial numbers for rows in the
table and the second column containing the key value for the row. The cells
in the second column may then use scope=row. The cells in the first row too
are marked up with  <td> and use scope=col.
<table border="1">
<caption>Contact Information</caption>
<td scope="col">Name</td>
<td scope="col">Phone#</td>
<td scope="col">Fax#</td>
<td scope="col">City</td>
<td scope="row">Joel Garner</td>
<td scope="row">Clive Lloyd</td>
<td scope="row">Gordon Greenidge</td>

Response from Working Group:

We have changed this technique as shown below. We kept your previous
example and included the link to Assistive Technology Reading Tables,
authored with David MacDonald and Jim Thatcher, in the Resources

User Agent and Assistive Technology Support Notes

The row and col values of the scope attribute are currently supported
to a large extent by most current versions of JAWS. However, there are
still some problems and WindowEyes' support for scope is inconsistent.
The same is true for Japanese versions of these screen readers.
Versions of JAWS prior to version 5 have inconsistent support for

At the current time, those who want to ensure consistent support
across Assistive Technologies for tables where the headers are not in
the first row/column may want to use the technique for complex tables
[H43: Using id and headers attributes to associate data cells with
header cells in data tables (HTML)]. For simple tables that have
headers in the first column or row we recommend the use of the [th/td


The objective of this technique is to associate header cells with data
cells using the scope attribute. The scope attribute may be used to
clarify the scope of any cell used as a header. The scope identifies
whether the cell is a header for a row, column, or group of rows or
columns. The values row, col, rowgroup, and colgroup identify these
possible scopes respectively.

For data tables where the header is not in the first row or column,
like the one in Example 1, this technique can be used.   Based on
screen reader support today, its use is suggested in two situations
both relating to simple tables:

1) data cells marked up with td that also function as row header or
column header

2) header cells marked up with td instead of th. Sometimes, authors
use this to avoid the display characteristics associated with th and
also do not choose to use CSS to control the display for th.

Note: for simple tables that have the headers in the first row or
column then it is sufficient to simply use the TH elements without

Note: for complex tables use id's and headers as in [H43: Using id and
headers attributes to associate data cells with header cells in data
tables (HTML)].

Comment 3: H74 and H75 - unclear why id attributes should be unique
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Feb/0002.html
(Issue ID: 1928)
Original Comment:

Refer HTML Techniques H74 and H75

Both have " Ensuring that all id attribute values are unique" as an
objective. It is unclear  why this should be so.

Make " Ensuring that all id attribute values are unique" a separate
technique. H74 and H75 can retain the remaining parts of their  statements
or may even be combined.

Response from Working Group:

We have revised the technique about unique ids as a failure for
success criterion 4.1.1. Since the concept of well-formedness does not
apply to HTML 4.01, we have chosen not to combine H74 and H75.

Comment 4: H73: table summary- wrong classification
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Apr/0001.html
(Issue ID: 1929)
Original Comment:

i. The table summary is an aid to understanding table content (G3.1 make
content readable and understandable, Principle #3) and is not related to
structure versus presentation (G1.3). Table summary helps understanding in
the same way as expansion of acronyms/ abbreviation helps understanding
ii. The summary attribute is not required for all data tables.
- The summary is  generally necessary for complex tables and may be a vital
aid for quick comprehension of such tables.
- The summary is useful for simple tables with many columns. It can also be
used to convey the purpose of the table when the caption is not used.
iv. In other cases it may be a nuisance .
The explanation following the H73 technique is apt

i. H73 should be a technique against G3.1 and not G1.3
ii. For complex tables the summary  should be  at level 1
iii. For the other two uses it may be  at Level 3 or Level 2.

Response from Working Group:

{not accept}

The 'summary' attribute value for a table conveys information about
the relationship of the data as it is conveyed visually. The layout of
data can be quickly ascertained by visual users, whereas this
information is most usefully described to screen reader users via the
'summary' attribute.
This means it is an appropriate technique for Success Criterion 1.3.1
(which is under Guideline 1.3).

This is a sufficient technique for Success Criterion 1.3.1. Success
criterion 1.3.1 is required at Level A

Having a 'summary' for simple tables with many columns provides
information that the table is a data table, as opposed to a layout
table, and a user can still find it useful to have a description of
the layout of data. A simple description may be sufficient and it is
enough to let the user know that the layout is a simple one and does
not require much cognitive effort to understand the layout - useful to
know when the user can not ascertain this visually.

Having a 'summary' for simple tables with two columns is still useful
if the table is a data table with column or row headers. If the data
in the table is simple enough to not require column or row headers,
then a data table implementation may not be the most appropriate
method to present the data (or may not be necessary).

Since 'techniques' cannot have levels and 'simple' and 'complex' are
hard to define objectively (and the technique can still be useful for
non-complex tables for some people) we have handled it in this

Comment 5: F61: Test Procedure #4
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0131.html
(Issue ID: 1934)
Original Comment:

F61 reads: Failure of SC 3.2.5 due to complete change of main content
through an automatic update that the user cannot disable from within the
Test Procedure 4 states: check if there are settings within the content to
disable automatic changes
Expected Results state:If both 3 and 4 are true, then this failure condition
applies and the content fails this success criterion.
If test procedure 4 is true, the content passes the test because the content
contains settings that disable automatic updates.
So change the expected results or re-word  test procedure 4 as:
Confirm that the content does not contain any settings to disable automatic

Response from Working Group:

We have revised test procedure #4 as proposed.

Comment 6: F42: state that items are not tab-navigable
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0074.html
(Issue ID: 1993)
Original Comment:

Refer to Common Failure F42 on
At present the description states:
"... or they may be recognized as interactive controls but still not
recognized as links. Such elements do not appear in the links list
generated by user agents or assistive technology."

Comment: A control or link created in this  manner cannot be tabbed to
from the keyboard and does not gain keyboard focus. Stating these are
not tab-navigable is a more direct way of conveying the issue  than
stating "does not appear inn a link list".

 I think this is important and missing from the description. Yes one
cannot perceive this to be a control or a link but it is also an
failure under 2.4.1.


1. State these are not tab-navigable  and cannot be accessed from the
keyboard like other controls / links

2. Consider this to be a failure under 2.4.1 as well.

Response from Working Group:

Thank you. We have modified the description of F42 to read:

This failure occurs when JavaScript event handlers are attached to
elements to "emulate links." A control or link created in this  manner
cannot be tabbed to from the keyboard and does not gain keyboard focus
like other controls and/or links.

We have also added F42 to the list of common failures in 2.1.1 and
have updated the title to "Failure of SC 1.3.1 and 2.1.1 due to using
scripting events to emulate links."

Comment 7: SC 2.4.1: use of term "block of content"
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0076.html
(Issue ID: 1994)
Original Comment:

Comment: The examples for block of content list navigation links,
heading graphics, and advertising frames.

G1.3 and SC 1.3.1 require structural markup so that content is
programatically determinable. That means user agents and assistive
technology can access these
blocks of content. So having stated this already why repeat this again
under 2.4.1? Why make content developers responsible to  provide a
mechanism to skip
any and all repetitive blocks of content? User agents now and in the
future may incorporate this function.

But like   WCAG 13.6 and S508 (para o of 1194.22) content authors
could be required to provide mechanism to skip groups of links
including repetitive
ones. This is especially useful when  links are not contained in a
separate frame, list or grouped under a heading tag etc. In this case
a "skip left navigation"
or "skip to content" link may be useful. In other cases  SC 1.3.1 will
already have  made the author mark up the block of content with
structural markup
and left user agents / AT to do the rest.

Suggestion: replace "block of content" in  SC 2.4.1 with groups of
links" Groups of links may be defined as four or more links placed one
after another and
include such groups that are repeated across multiple Web pages.

Response from Working Group:

Success criterion 2.4.1 is intended to apply to all largish blocks of
repetitive content, not just links, although navigation links is one
of the common cases. We have clarified the intent to indicate that
small bits of repeated content are excluded.

Note: It is worded as "a mechanism is available" because of success
criterion 1.3.1. If the document structure provided under 1.3.1 allows
user agents to support skipping the content, then a mechanism is
available and this success criterion is satisfied. We have added a
technique to indicate that using an accessibility supported technology
which allows structured navigation is sufficient.

Where it cannot be ascertained by the author that the user agents can
provide directly, or work with AT to provide such a feature on the
basis of the structure provided, it would require the author to
provide an explicit mechanism.

Comment 8: Consider this technique for 2.4.1
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0077.html
(Issue ID: 1995)
Original Comment:

Sub: Documenting additional technique for skipping
over links (SC2.4.1)

Technology: HTML / XHTML with CSS and Java scripting
Description of technique:
Expandable / collapsable menu
Consider a list of image  links: Animals, Flowers,
Birds in a menu
There is an image (plus  and minus) or arrow marks
that convey if menu is expanded or collapsed next to
each of the above menu item. These may be assigned
null alt.

Using CSS and JS a menu item maybe expanded to reveal
a list of additional links in that group.. The alt for
the image should be set to
Animals ... menu item expanded   or
Animals ... menu item collapsed
Flowers ... menu item expanded   or
Flowers ... menu item collapsed
and so forth.

So by collapsing the menu item-links a user is able to
skip over groups of links. No other mechanism to skip
over the links may be needed.

Response from Working Group:

Thank you. we have added a placeholder technique titled
"Using an expandable and collapsible menu". Would you be able to write
this one up and submit it? The technique submission form can be found
at http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/ .

Comment 9: Not ok with use of term Level-A, Level-AA, AAA
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0233.html
(Issue ID: 2357)
Original Comment:

Refer to the following statements from WCAG 2.0:
"They (meaning the SC) are similar to the
"checkpoints" in WCAG 1.0
WCAG 2.0 success criteria are organized into three
levels of conformance.
The word "levels" does not mean that some success
criteria are more important than others. Each success
criterion in WCAG 2.0 is essential to some users, and
the levels build upon each other. However, even
content that conforms at AAA (triple-A) may not be
fully accessible to every person with a disability or
combination of disabilities, especially certain types
of severe disabilities.
It is recommended that even if content does not
conform at a specific level, that it conform to the
extent possible."

The document does state that the SC are akin to WCAG 1
checkpoints. WCAG 2 also uses level-A, AA and AAA
conformance like WCAG 1.0.
Although the WCAG2 doc clarifies that '"levels" does
not mean that some success criteria are more important
than others', I feel the terminology used will lead to
a lot of confusion to the detriment of accessibility.
Most will interpret a level-A SC as superior in terms
of accessibility than a level-AA SC. (see example
below) It is as if I am saying my Web content is
superior in terms of accessibility if I meet a level-A
SC than a level-AAA SC (Present definition of
level-AAA: Level AAA success criteria increase both
direct access and access through assistive technology)
This type of competition is bad for accessibility.

WCAG2 is about enhancing accessibility.
The three types of SC should be simply called
Category-1, Category-2 and Category-3 - they simply
are three buckets into which various methods of
meeting a guideline can be dumped. Let developers
decide which method they wish to use. There may be
those, who in the interests of accessibility, may
choose to implement a level-AAA (or Category-3- my
term) method to provide enhanced accessibility instead
of a level-A method. Alternative terms are Tier-1,
Tier-2, Tier-3 or simply, Type-1, Type-2, Type-3.

Example - a level-AAA SC being regarded as inferior
than level-A SC:
In "WCAG 2.0 - Polishing the rough edges", Jared Smith
rightly argues that transcripts are a superior method
for implementing accessibility (SC 1.2.7) than
captions. He also makes a case for labeling
transcripts as a level-A (or Category-1 method in my
parlance). That is another point. But when he states,
"_relegating_ transcripts to level AAA is a mistake",
I believe he too interprets that WCAG2 regards
transcripts as an inferior method as compared to

Sailesh Panchang
Phone 571-344-1765

Response from Working Group:

We have looked at several different conformance models including one
that has just SHALL and SHOULD provisions. It was found that that
approach would not work for the variety of sites and uses the
guidelines would have to meet. In the end, and after much discussion ,
it was determined that the three tier approach would work best.

As to naming we also looked at a number of different approaches
including ones that were non-hierarchical.  However, the levels are
hierarchical.  You must conform at level A before claiming AA etc.
So non-hierarchical names would be confusing.

Regarding Jared's comment - he was not referring to level of access
but rather probability of implementation.  Since level A is required,
any that is not in level A is less likely to be applied.
Received on Sunday, 4 November 2007 05:10:12 UTC

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