Your comments on WCAG 2.0 Last Call Draft of April 2006

Dear Geoff Freed ,

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
archived.

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/20060524131018.DBC6B47BA1@mojo.w3.org
(Issue ID: LC-586)

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

Re the statement, \"Following these guidelines will also make your Web
content more usable to many other users, including older users.\":
Older users?!  Really?  How old?  Over 40?  50?  60?  Is there proof
that \"older users\" need help using the Web just because they\'re
over a certain age?

Proposed Change:

Delete this sentence.

----------------------------
Response from Working Group:
----------------------------

Not all older people have disabilities.  However, the percentage
increases steadily and sharply with age. We have clarified this by
changing the sentence to "Because many people develop vision, hearing,
cognitive or motion impairments as they age, following these
guidelines will make your Web content more usable by many older
users."

----------------------------------------------------------
Comment 2:

Source: http://www.w3.org/mid/20060524152938.02C93BDD3@w3c4.w3.org
(Issue ID: LC-590)

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

My main objection to WCAG 2.0 is that it is simply too big.  Brevity
has been abandoned in favor of excessive, often pedantic, discussion.
Developers coming to WCAG 2.0 will want immediate, accessible answers
that address their problems.  Instead, they must follow multiple links
in order to gain information about even the simplest topics (e.g.,
text alternatives).  It\'s often necessary to wade through lengthy
explanations and rationalizations before arriving at useful
information, and this information is frequently cloaked in roundabout
language (\"baseline?\"  \"Web unit?\")  that never makes a direct
point.

If the W3C releases WCAG 2.0 in anything resembling its current form--
not just the guidelines document, but the related documents as well,
because WCAG 2.0 can\'t really be used without them-- it must then be
prepared to defend this document from backlash by a perplexed,
bewildered general public.  WCAG 2.0 is longer and more labyrinthine
than most other recommendations published by the W3C.  What does that
say about accessibility?  It\'s hard to achieve?  It\'s overly
complex?  It\'s a big pain in the neck?  If the WAI wants these
*voluntary* guidelines to be widely adopted, they must be re-written
in a concise, direct manner.

Proposed Change:

----------------------------
Response from Working Group:
----------------------------

We have reworked the entire document to make it shorter and easier to
read. This includes:
- Shortening the introduction
- Moving much of the discussion out of the guidelines and puttin it in
the Understanding WCAG 2.0 document
- Shortening the conformance section and moving it after the guidelines
- Writing simpler guidelines
- Removing as many technical terms (jargon) as possible, replacing
them with simpler language or their definitions
- Removing the nesting of definitions where we could (i.e. definitions
that pointed to other definitions)
- Moving information about mapping between WCAG 1 and WCAG 2 to a
separate support document (so it can be updated more easily)
- Creating a Quick Reference documents that has just the Guidelines,
success criteria and the techniques for meeting the success criteria.
- Trying to word things in manners that are more understandable to
different levels of Web expertise
- Adding short names/handles on each success criterion to make them
easier to find and compare etc.
- Simplifying the conformance section
- Using plainer language wherever possible (e.g. – use "Web page"
instead of "Web Unit")
- Eliminating several new or unfamiliar terms. (authored unit, etc.)
- Making the whole document much shorter.


----------------------------------------------------------
Comment 3:

Source: http://www.w3.org/mid/20060524154653.398B366379@dolph.w3.org
(Issue ID: LC-598)

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

Level 1 SC for Guideline 1.2 should also include live captioning.  By
assigning live captions to Level 2, the working group is designating
this as less important than pre-produced captions.  In fact, live
captions are arguably more important than pre-produced captions--
consider the case of an emergency alert.

Proposed Change:

Move live captioning to Level 1.

----------------------------
Response from Working Group:
----------------------------

The group considered this carefully. Part of the criteria for Level A
is that it can reasonably be applied to all Web content. Unlike
captioning for prerecorded video, live captioning can not be done by
the author, but requires people with very specialized training and
skills to transcribe in real time.

----------------------------------------------------------
Comment 4:

Source: http://www.w3.org/mid/20060524155533.51BB447BC6@mojo.w3.org
(Issue ID: LC-599)

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

A full multimedia transcript is not an alternative to audio
description.  (In fact, I doubt its usefulness in general.)  Audio
descriptions should be required at Level 1, period.

Proposed Change:

Delete the reference to a full multimedia transcript.  Move 1.2.3 up to 1.2.2.

----------------------------
Response from Working Group:
----------------------------

After much discussion, the group felt that a full transcript should be
allowed as an alternative. A full transcript provides all the
information from the multimedia (visual and auditory). That has been
our measure for an accessible alternative. It does not provide the
same experience, but text alternatives to graphics do not provide the
same experience either. In addition, audio-description does not always
provide all of the information that is presented visually. For example
audio description may not provide all of the information in a training
video which is almost all speaking over top of the visuals. In this
case, a full text alternative (audio and visual) would give more
information than just an audio description.

It was decided to allow the option to provide either audio description
or a full text transcript at level A.

----------------------------------------------------------
Comment 5:

Source: http://www.w3.org/mid/20060524160247.B35E547BD9@mojo.w3.org
(Issue ID: LC-601)

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

Live audio descriptions must also be included in Level 1 SC for Guideline 1.2.

Proposed Change:

Insert a requirement for live audio descriptions into Level 1 SC for
Guideline 1.2.

----------------------------
Response from Working Group:
----------------------------

Unless live action is scripted, there is no way to know when the gaps
will occur so that live audio description can be done (unless it is
video footage which essentially has no audio dialog or, you are going
to delay broadcast by some significant amount).

----------------------------------------------------------
Comment 6:

Source: http://www.w3.org/mid/20060524161346.16F2ABDF3@w3c4.w3.org
(Issue ID: LC-602)

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

It is unrealistic to ask authors to provide an alternative version of
a Web site, or any other material, using language written at a lower
reading level than the original material.

Proposed Change:

Delete requirement 3.1.5.

----------------------------
Response from Working Group:
----------------------------

Providing an alternate version that is easier to read is one of the
forms of supplemental content that satisfies SC 3.1.5, but is not
required. This is also at Level AAA, so it may not be possible for all
Web pages.

----------------------------------------------------------
Comment 7:

Source: http://www.w3.org/mid/20060524181521.9002CBDD3@w3c4.w3.org
(Issue ID: LC-603)

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

These comments also apply to 1.4.1:

1.  Is it realistic to expect authors to do the math to figure out the
luminosity contrast ratio?
2.  Why isn\'t MathML used to represent the equations?
3.  If the only difference between 1.4.1 and 1.4.3 is the ratio (5:1
vs 10:1), then drop one ratio and therefore one needless requirement.

Proposed Change:

1.  Use MathML to represent the equations.
2.  Eliminate either 1.4.1 or 1.4.3, preferably the latter.
3.  Reconsider the expectation that authors will determine contrast
through the use of the luminosity contrast ratio.  Did anyone in the
working group poll authors to see if this is realistic?

----------------------------
Response from Working Group:
----------------------------

Authors do not have to use the luminosity contrast ratio to determine
their contrast ratio. In the resources section, a list of tools have
been provided that already do this. One uses an eye dropper and is
very easy to use. We have added a note to the intent sections of both
SC 1.4.3 (formerly 1.4.1) and SC 1.4.5 (formerly 1.4.3) that refers to
the list of these tools to make it more obvious that these tools are
available.

Because support for MathML varies across browsers and platforms,
because the information from the equations can be mis-presented in
some cases, and because it was possible to represent the luminosity
contrast ratio in ASCII, a MathML version of the equations was not
included in the guidelines themselves. We have, however, added a note
to the definition which points to a MathML version. Should support
MathML change prior to publication, we will include this version in
the guidelines themselves.

The working group determined that there is a significant improvement
of readability between 10:1 and 5:1 but that 5:1 was sufficient in
most cases and 10:1 is very demanding, basically white on black or
vice versa.

----------------------------------------------------------
Comment 8:

Source: http://www.w3.org/mid/20060526154936.C45B2DAEAC@w3c4-bis.w3.org
(Issue ID: LC-649)

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


Regarding baseline:  I\'ve read and re-read all the documentation
about baseline and I just don\'t understand it.  It seems like
baseline is a great way to blame the victim:  an author can claim that
a user\'s accessibility problems are, in fact, strictly his or her
problems.  The answer to any complaint is, \"That\'s not in my
baseline, so I didn\'t test for it.\"  The only way it might be useful
is in a closed environment, such as an Intranet, where authors really
do know what technologies users have.  And the fact that baseline
requires an entirely separate explanatory document indicates to me
that it is *far* too complex to be useful.

Regarding scoping:  \"Scoping\" of a conformance claim introduces a
perfect loophole for anyone who simply doesn\'t want to do the work
required to make things accessible.  Take Example 2:  \"A site has a
collection of videos for which it is not required to and does not want
to claim accessibility.\"  \"Not required?\"  But aren\'t captions
required by SC 1.2?  Is \"I don\'t want to\" now a valid excuse?
Further, Example 2 states that a scoped conformance claim of \"I
don\'t want to caption/describe the videos\" is valid as long as the
videos are played only in a standalone player.  But if the videos are
embedded in a Web page, suddenly they *must* be made accessible...?  I
don\'t see the distinction.  Video is video.  If I\'ve created an
on-line physics curriculum that uses a standalone player to show an
entire semester of lectures, you\'re saying that these videos do *not*
have to be accessible if I \"scope\" my conformance claim to exclude
these materials?


Proposed Change:


1.  Delete baseline.
2.  Delete scoping.

----------------------------
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 .

The guidelines and success criteria remain technology-independent, in
order to allow conformance using any Web technology. In choosing Web
technologies, 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."

To make it easier for authors who may not be familiar with assistive
technologies, documented lists of technologies that are accessibility
supported will be available from WAI and other sources.

The "Scope out" language has now been removed from the Conformance
section and conformance is now based on Web page(s):  that is a
primary resource referenced by a URI and any other resources that are
rendered simultaneously with it with the understanding that different
sub elements or resources may be rendered simultaneously with the
primary resource at different points in time.

Received on Thursday, 17 May 2007 23:33:57 UTC