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

Your comments on WCAG 2.0 Last Call Draft of April 2006

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Thu, 17 May 2007 16:43:31 -0700
Message-ID: <824e742c0705171643m2e061803hc9101b39f2bcecbb@mail.gmail.com>
To: "Sean Curran" <sean@srcurran.com>
Cc: public-comments-WCAG20@w3.org

Dear Sean Curran ,

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/20060622205348.5E12F47BA1@mojo.w3.org
(Issue ID: LC-948)

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

It would be helpful to show working examples of the code sample given.
This would be useful in other places in the document as well. I don\'t
want to create HTML files for each example.

Proposed Change:

Create the working examples.

Response from Working Group:

This is already true for some of our examples.  We intend to continue
to create working examples and convert examples to working examples as
we continue to develop the Techniques document(s) and other support

We have added a note to the status section of the techniques draft to
clarify our plans to include working examples.

Comment 2:

Source: http://www.w3.org/mid/20060622210606.57A0D33201@kearny.w3.org
(Issue ID: LC-964)

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

Highlighting information should also be mentioned. Many people
highlight text using just a span and it is a cue to visusal users but
not to computer devices.

Proposed Change:

Add highlighting to the list that includes emphasising, headers,
strong, etc. I recommend that highlighting is a special form of em tag
using css.

Response from Working Group:

SC 1.3.1 and 1.3.4 have been combined to read "Information and
relationships conveyed through presentation can be programmatically
determined or are available in text, and notification of changes to
these is available to user agents, including assistive technologies."
The How To Meet document for this combined success criterion does
include highlighting via a background color in the intent section.  In
addition, another example about highlighting has been added to
Technique G115: Using semantic elements to mark up structure.

Comment 3:

Source: http://www.w3.org/mid/20060622211255.5126133201@kearny.w3.org
(Issue ID: LC-975)

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

Multimedia documents are not mentioned. There are many flash documents
that have a constantly moving background which is highly distracting.

Multimedia should also be mentioned with luminosity  and other
sections. It may, however, be out of the scope of the document.

Proposed Change:

Include multimedia in the recomendations so people will not be in
compliance if they use obnoxious moving backgrounds.

Response from Working Group:

This is covered by Success Criterion 2.2.3. The background would need
to be paused unless it were essential.

Comment 4:

Source: http://www.w3.org/mid/20060622205348.5E12F47BA1@mojo.w3.org
(Issue ID: LC-980)

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

A few other pointers that should be included.

-Don\'t use the same term/word/sentince to symbolize a link if they go
different places
-show links have been visited
-don\'t recommend to repeat the same text over and over hard on screen readers.

Proposed Change:

Add the aditional pointers.

Response from Working Group:

Success criterion 3.2.4, "Components that have the same functionality
within a set of Web pages are identified consistently." means that
links that go to the same place should have the same description. If
links that go to different places have the same description, then the
description is not sufficient to determine the purpose of the link.
The Intent section of How To Meet SC 2.4.4 points this out: "Links
with the same purpose and destination are associated with the same
description (per Success Criterion 3.2.4), but links with different
purposes and destinations are associated with different descriptions."

Showing links that have been visited is a User Agent responsibility,
and is required by Checkpoint 10.2 of the User Agent Accessibility
Guidelines (Highlight selection, content focus, enabled elements,
visited links). Success Criterion 4.1.2 has been modified to require
that the state of interactive controls be programmatically determined,
so that user agents can satisfy this requirement.

Avoiding unnecessary text repetition is an issue that the working
group has struggled with. Often, text repetition is introduced by the
desire to have link descriptions that make sense when read out of
context. SC 2.4.4 permits links to have descriptions that depend on
their context, so that contextual information won't have to be

Comment 5:

Source: http://www.w3.org/mid/20060622211818.2453533201@kearny.w3.org
(Issue ID: LC-985)

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

Also applies to other sections.

The content must be identical. If you allow people to use mutliple
versions, you must tell them that they have to keep the two identical
because it is an easy way to create discrepancies and then there is an
information gap. I would rather have one accessible version that

Proposed Change:

Response from Working Group:

While we agree that a single accessible version is desirable, the
working group recognizes that there can be good reasons for providing
multiple versions. The author may wish to provide different versions
that use different sets of technologies, or may wish to provide
versions that are tailored for people with particular disabilities.

To make it clearer that the content must be equivalent, we have
revised the definition of alternate version:
"version that provides all of the same information and functionality
in the same natural language and is as up to date as any of the
non-conformant content"

In addtion, we have revised the conformance section on alternate versions:

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.

Comment 6:

Source: http://www.w3.org/mid/20060622212402.1F3CF66364@dolph.w3.org
(Issue ID: LC-986)

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

I would add another section to 3.1 that alows users to increase or
decrease the text size through the browser or the website. Or the text
will work with multiple default text sizes. I think this is a bigger
deal than screen readers and zooming in. Most 50  people have bad
eyesight and don\'t know how to use windows zoom, but can be taught
the make text bigger trick and have it as a large size by default.
This breaks some websites and makes the content un-usable.

Proposed Change:

Add a section under 3.1 that allows users to increase the text size a
reasonable amount and still have the website readable/usable/etc.

Response from Working Group:

Although resizing is primarily a user agent function, we have added
new success criteria to address the author's responsibility for
supporting text resizing:

Level AA: Visually rendered text can be resized without assistive
technology up to 200 percent and down to 50 percent without loss of
content or functionality.

Level AAA: Visually rendered text can be resized without assistive
technology up to 200 percent and down to 50 percent without loss of
content or functionality and in a way that does not require the user
to scroll horizontally.
Received on Thursday, 17 May 2007 23:43:48 UTC

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