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

Your comments on WCAG 2.0 Last Call Draft of April 2006 (1 of 3)

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Thu, 17 May 2007 16:30:46 -0700
Message-ID: <824e742c0705171630g61c2790bt1a75a1ac810f74d6@mail.gmail.com>
To: "Andrew Arch" <andrew.arch@visionaustralia.org>
Cc: public-comments-WCAG20@w3.org

Dear Andrew Arch ,

Thank you for your comments on the 2006 Last Call Working Draft of the
Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2006/WD-WCAG20-20060427/). 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
http://lists.w3.org/Archives/Public/public-comments-wcag20/, and may
also include links to the relevant changes in the updated WCAG 2.0
Public Working Draft at http://www.w3.org/TR/2007/WD-WCAG20-20070517/.

PLEASE REVIEW the decisions  for the following comments and reply to
us by 7 June at public-comments-WCAG20@w3.org 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
http://www.w3.org/WAI/GL/2007/05/change-summary.html . Please see
http://www.w3.org/WAI/ 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:

Source: http://www.w3.org/mid/003001c69588$f46e5480$011610ac@yourdh7axfhyur
(Issue ID: LC-1261)

Comment: para 1 says "as a result authoring tools WILL play an
important role ..." - implying a future role for authoring at some
time in the future. Authoring tolls paly an important role NOW.

Proposed Change:

change wording to "as a result authoring tools play an important role ..."

Response from Working Group:

This was meant to refer to the future when WCAG 2.0 was out. But this
wording should be written to match that future. The draft has been
updated as proposed. Good catch.

Comment 2:

Source: http://www.w3.org/mid/003001c69588$f46e5480$011610ac@yourdh7axfhyur
(Issue ID: LC-1262)

Comment: para 2 talks about ATAG 1.0 and ATAG 2.0 in relation to the
current date. This sentence will date rapidly depending on the
relative releases of WCAG 2.0 and ATAG 2.0.

Proposed Change:

change wording to reflect the 'current' ATAG release - possibly by
specifying ATAG 1.0 release year and just saying that ATAG 2.0 is due
for release in 200x (x = 6/7/8??)

Response from Working Group:

Direct discussion of the role of authoring tools has been removed from
WCAG. The Components of Web Accessibility section directs readers to
the ATAG overview.

Comment 3:

Source: http://www.w3.org/mid/003001c69588$f46e5480$011610ac@yourdh7axfhyur
(Issue ID: LC-1263)

Comment: the term 'web unit' needs some examples about when the term
'web page' may not apply

Proposed Change:

add some examples to "..may not apply" such as 'webcast' or 'multimedia object'

Response from Working Group:

We have replaced the term "Web unit" with "Web page" and have modified
the section on new terms,
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#new-terms, to describe
our use of the term "Web page" in greater detail. We have also added
an example of content that may not immediately be recognized as a "Web
page." See http://www.w3.org/TR/2007/WD-WCAG20-20070517/#webpagedef .

Web page

    a resource that is referenced by a URI and is not embedded in
another resource, plus any other resources that are used in the
rendering or intended to be rendered together with it

    Note: Although any "other resources" would be rendered together
with the primary resource, they would not necessarily be rendered
simultaneously with each other.

    Example 1: When you enter http://shopping.example.com/ in your
browser you enter a movie-like interactive shopping environment where
you visually move about a store dragging products off of the shelves
around you into a visual shopping cart in front of you. Clicking on a
product causes it to be demonstrated with a specification sheet
floating alongside.

    Example 2: A Web resource including all embedded images and media.

    Example 3: A Web mail program built using Asynchronous JavaScript
and XML (AJAX). The program lives entirely at http://mail.example.com,
but includes an inbox, a contacts area and a calendar. Links or
buttons are provided that cause the the inbox, contacts, or calendar
to display, but do not change the URL of the page as a whole.

    Example 4: A customizable portal site, where users can choose
content to display from a set of different content modules.

Comment 4:

Source: http://www.w3.org/mid/003001c69588$f46e5480$011610ac@yourdh7axfhyur
(Issue ID: LC-1264)

Comment: Why do we need to say that Triple-A only requires conformance
to a portion of the level 3 SC? This was the case in WCAG 1 at all
levels and we just used to say NA (not applicable) for a checkpoint if
there was no multimedia or no frames etc. This particularly relates to
the later section suggesting that only 50% of level 3 SC need to be
met to claim Triple-A

Proposed Change:

rephrase this Note to specify that not all level 3 SC might apply, and
a web unit only needs to conform to the applicable ones to claim
triple-A conformance

Response from Working Group:

We have changed the definition of Level AAA conformance so that all
Level AAA success criteria that apply to the content types used must
be satisfied.

Comment 5:

Source: http://www.w3.org/mid/003001c69588$f46e5480$011610ac@yourdh7axfhyur
(Issue ID: LC-1265)

Comment: para 3 - "even conformance to all three levels will not make
web content accessible to all people". Some guidance needs to be
provided as to what else is required to make the content accessible to
all - OR who is not included in WCAG 2.0

Proposed Change:

additional references/pointers are required

Response from Working Group:

Due to the wide variability on many dimensions of human ability, there
are people who necessarily fall beyond the limits that a practicable
set of guidelines can address. WCAG 2.0 addresses all disabilities to
some extent, but none absolutely, and the focus is to create a set of
guidelines that provides the broadest coverage possible while
remaining reasonable for general-purpose guidelines. There is no easy
way to describe the boundaries, especially given the continuing
development of technologies. We have tried to provide information
regarding coverage in the benefits sections and advisory techniques
that can also be used to make pages more accessible than the minimum
standard required by WCAG.

Comment 6:

Source: http://www.w3.org/mid/003001c69588$f46e5480$011610ac@yourdh7axfhyur
(Issue ID: LC-1266)

Comment: para 3 - "... all SC are essential for some people". However,
the previous para indicates that Level 1 is sufficient to provide a
minimum level of accessibility. This is contradictory.

Proposed Change:

address the contradiction

Response from Working Group:

The description of conformance levels in WCAG 2 has been rewritten to
clarify the differences (see
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-levels ):

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.

* In general, Level A success criteria achieve accessibility by
supporting assistive technology while putting the fewest possible
limits on presentation. Thus people with a wide range of disabilities
using a wide range of assistive technologies, from voice input and
eye-tracking devices to screen readers and screen magnifiers, are able
to access content in different ways. In other words, Level A success
criteria support the ability of both mainstream and specialized user
agents to adapt content to formats that meet their users' needs.

* The success criteria in Level AA provide additional support for
assistive technology. At the same time, they also support direct
access to content by the many people who use conventional user agents
without assistive technology. In general, Level AA success criteria
place more limits on visual presentation and other aspects of content
than the success criteria in Level A.

* Level AAA success criteria increase both direct access and access
through assistive technology. They place tighter limits on both
presentation and content.

Comment 7:

Source: http://www.w3.org/mid/003001c69588$f46e5480$011610ac@yourdh7axfhyur
(Issue ID: LC-1267)

Comment: para 4 - "When people who understand WCAG 2.0 test the same
content using the same success criteria, the same results should be
obtained with high inter-rater reliability". More than just an
understanding of WCAG 2.0 is required - these people also need an
understaning of how PWD interact with the web, with or without
assistive technologies.

Proposed Change:

add something extra to the qualifications that WCAG 2.0 testers are
required to have to obtain the same results.

Also suggest changing "high inter-rater reliability" to "high
inter-tester reliability"

Response from Working Group:

The qualifications to be a WCAG 2.0 tester are not formalized, and the
quantification of knowledge skills and abilities to do so is beyond
the scope of this document.  We do agree that a qualified individual
should have background in disability and not just the web.

We have revised the conformance section significantly since the April
2006 working draft. The sentence related to your comment, in
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-sc, now reads:

"The same results should be obtained with a high level of confidence
when people who understand how people with different types of
disabilities use the Web test the same content."

Comment 8:

Source: http://www.w3.org/mid/003001c69588$f46e5480$011610ac@yourdh7axfhyur
(Issue ID: LC-1268)

Comment: Note (para 5) - reads like an 'out' - could be taken to give
developers the option of using any technique they deem to be
accessible, regardless of how a PWD uses the web

Proposed Change:

Strengthen/change the Note to make it clearer what a developer is
expected to do. No concrete suggestion.

Response from Working Group:

The Working Group is not in a position to identify all possible
techniques in all possible technologies that could be used to satisfy
a success criterion, particularly as user agents and assistive
technology continue to evolve. The sufficient techniques are listed to
provide developers with guidance on approaches that are known to be
acceptable. A developer who uses a different technique needs to
justify how that technique is sufficient for the success criterion. We
have added the following sentence to the paragraph to emphasize that
this should not be done lightly:

"When using such externally-provided techniques to meet WCAG 2.0
requirements, it is important that they be created by individuals or
organizations who are knowledgeable about the requirements of WCAG 2.0
and the needs of people with disabilities."

Comment 9:

Source: http://www.w3.org/mid/003001c69588$f46e5480$011610ac@yourdh7axfhyur
(Issue ID: LC-1269)

Comment: para 2 - User agents not only "help in retrieving and
rendering Web content", but also in interacting with web content

Proposed Change:

change sentence to "help in retrieving, rendering and interacting with
Web content"

Response from Working Group:

This sentence no longer occurs in the introduction. However, we have
changed the definition of user agent in the glossary as you proposed.

Comment 10:

Source: http://www.w3.org/mid/003001c69588$f46e5480$011610ac@yourdh7axfhyur
(Issue ID: LC-1270)

Comment: para 1 - "assume" is dangerous - they need to "know" the
technologies "are" supported.

Proposed Change:

change sentence from "authors need to know what technologies they can
assume will be supported by" to "authors need to know what
technologies are supported by"

Response from Working Group:

We agree that the use of "assume" was open to misinterpretation. We
have changed the wording to read:

In choosing Web technologies (HTML, scripting, etc.) that will be used
when creating content that will meet the WCAG 2.0 success criteria,
authors must use technologies that are supported by users' assistive
technologies as well as the accessibility features in browsers and
other user agents. Such technologies are referred to as "accessibility

Comment 11:

Source: http://www.w3.org/mid/003001c69588$f46e5480$011610ac@yourdh7axfhyur
(Issue ID: LC-1271)

Comment: para 2 - "browser" is used - should it be "user agent"?

Proposed Change:

consider changing sentence "since some users many have user agents
that support them"

Response from Working Group:

Thanks. This section has been completely rewritten and this error removed.

Comment 12:

Source: http://www.w3.org/mid/003001c69588$f46e5480$011610ac@yourdh7axfhyur
(Issue ID: LC-1272)

Comment: para 1 - I didn't understand "customers" setting baselines -
for a large organisation doing it's own development, the concept of
its 'customers' setting the basleine is ridiculous

Proposed Change:

openiong sentence may need clarification

Also - 'governmental' does not seem right, should it just be 'government'?

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
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#accessibility-support .

WCAG doesn't specify who might set create a documented lists of
accessibility-supported Web Technologies. It describes the
requirements for a technology to be considered accessibility
supported. Although the author is responsible for choosing
accessibility-supported technologies, we recognize that extensive
knowledge of the capabilities of user agents and assistive
technologies is needed to make this choice. We hope that knowledgeable
organizations will become repositories of this knowledge and make it
available to authors so that they can make well-grounded choices.

Comment 13:

Source: http://www.w3.org/mid/003001c69588$f46e5480$011610ac@yourdh7axfhyur
(Issue ID: LC-1273)

Comment: Examples of scenarios do not seem realistic - what happened
to Banks, News sites, Supermarkets, etc providing private services
online or selling goods online?

Proposed Change:

more examples are needed - or relegate the examples to the "About
Baseline" accompanying document

Response from Working Group:

The concept of baselines has been completely rewritten.  WCAG now
discusses accessibility-supported web technologies (i.e. technologies
that are used to create content that work with users' assistive
technologies and access features in browsers):
"In choosing Web technologies (HTML, scripting, etc.) that will be
used when creating content that will meet the WCAG 2.0 success
criteria, authors must use technologies that are supported by users'
assistive technologies as well as the accessibility features in
browsers and other user agents. Such technologies are referred to as
"accessibility supported."

So the question becomes "What technologies are considered
accessibility supported for public web pages?", that is, web pages for
which the author has no special knowledge about what user agents and
assistive technologies are available to users.

To answer this, one would need need:
1. Accessibility support analyses for candidate technologies,
documenting the user agent (browser and assistive technology) support
for that technology.
2. Analysis of browser and assistive technology available to users.

Ideally, this information would be gathered in a publicly available
location that could be consulted by anyone creating a public website.
Until such a database is available, it may be necessary for authors to
consult with knowledgeable sources for advice.

Comment 14:

Source: http://www.w3.org/mid/003001c69588$f46e5480$011610ac@yourdh7axfhyur
(Issue ID: LC-1274)

Comment: In the discussion of baseline and conformance, it seems that
there is potential for misuse of baseline [e.g.
authors might be able to just declare their own level of technology,
for instance: "requires CSS2 and JavaScript 1.2." The actual/potential
audience, not just perceived/target audience or what developers wish
they could reply on, should define baseline.

W3C/WAI should consider setting realistic excample baslines for
'everyday' websites in developed/LD countries.

Proposed Change:

Some possible strategies include:

a) to give guidance on what is a realistic baseline for most Internet sites
today, W3C should publish a 'reasonable/realistic' baseline
recommended for a general audience;
b) update this 'recommended' baseline annually;
c) place the 'recommended' baseline outside of the WCAG 2.0 normative document;
d) provide an explanation about why the particular baseline is recommended

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 discussion
of the term "Accessibility Supported" in
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#new-terms and in the
conformance section "Accessibility Support of Web Technologies" at
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#accessibility-support .

Comment 15:

Source: http://www.w3.org/mid/003001c69588$f46e5480$011610ac@yourdh7axfhyur
(Issue ID: LC-1275)

Comment: I disagree with allowing 50% conformance as sufficient for a
AAA pass - we should take the same approach as WCAG 1.0 and require
all checkpoints to be passed unless they are 'not applicable'. This
approach still works with the concept that not all level 3 SC will
apply to all web content.

Proposed Change:

change from 50% to "100% unless not applicable"

Response from Working Group:
Received on Thursday, 17 May 2007 23:31:08 UTC

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