Your comments on WCAG 2.0 Last Call Draft of April 2006

Dear Priti ,

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

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

Web authors can easily conform to this success criteria by simply
providing a descriptive text label for non-text content. By providing
the option to define only the purpose of the non-text content, we are
giving the developer the option of ignoring accessibility.

Proposed Change:

Response from Working Group:

Thank you for your comment. The only times it is acceptable to simply
identify the purpose of the non text content are described by the
situations listed in the revised criterion. For example, for a Webcam
at a ski resort, the Web site might offer information on the snowfall
amount for the last 24 hours, but the Webcam allows users who can see
to actually see what the weather is at that moment in time. Because
the Webcam is live video-only, a text alternative cannot provide
equivalent information and so a descriptive text label is sufficient.
We have modified 1.1.1 as follows:

1.1.1 Non-text Content: All non-text content has a text alternative
that presents equivalent information, except for the situations listed

    * Controls-Input: If non-text content is a control or accepts user
input, then it has a name that describes its purpose. (See also
Guideline 4.1 Maximize compatibility with current and future user
agents, including assistive technologies )
    * Media, Test, Sensory: If non-text content is multimedia , live
audio-only or live video-only content, a test or exercise that must be
presented in non-text format , or primarily intended to create a
specific sensory experience , then text alternatives at least identify
the non-text content with a descriptive text label. (For multimedia,
see also Guideline 1.2 Provide synchronized alternatives for
multimedia .)
    * CAPTCHA: If the purpose of non-text content is to confirm that
content is being accessed by a person rather than a computer, then
text alternatives that identify and describe the purpose of the
non-text content are provided and alternative forms in different
modalities are provided to accommodate different disabilities.
    * Decoration, Formatting, Invisible: If non-text content is pure
decoration, or used only for visual formatting, or if it is not
presented to users, then it is implemented such that it can be ignored
by assistive technology.

Comment 2:

(Issue ID: LC-819)

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

If the given situation is true and the user is given 20 seconds to
react…it will become difficult for people using Assistive Technology,
such as screen readers to read the message and react within 20
seconds. Even if the user is needed to only press a key, with a screen
reader  listening to the warning alone might require more then 20
seconds. This time should be extended and not fixed based on the

Proposed Change:

Response from Working Group:

The working group acknowledges that 20 seconds may not be enough for
all users in all circumstances but felt that 20 seconds was a
reasonable amount of time to require. The message informing the user
is expected to be very short and screen reader users typically listen
at very high rates of speed.

Received on Thursday, 17 May 2007 23:42:30 UTC