Your comments on WCAG 2.0 Last Call Draft of April 2006

Dear Rich Caloggero ,

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/20060526201139.C75DEBDA8@w3c4.w3.org
(Issue ID: LC-651)

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

 I think 2.0 is bloated, and hard to understand. I can see on the one
hand why it might need to be a bit more weighty than 1.0 because its
scope is much wider (other formats besides HTML are considered).
However, what they have come up with is exceedingly complex,
convoluted, and not very comprehensible. Its not going to make
promotion of accessibility any easier or more practical. In fact, it
may have the opposite effect; people will avoid it like the plague,
because they don\'t understand it, and they don\'t have time or energy
to bother trying!

 I\'m not sure exactly what this means in practical terms. I see large
corporations saying \"we don\'t have time to deal with this\", and the
\"little guys\" just won\'t be bothered at all.


Proposed Change:

 I think that instead of trying to incorporate all technologies and
all \"disabilities\" into one large framework, WAI should consider
breaking it up by technology (HTML/web, PDF and other stand-alone
\"document\" formats, etc). Of course, then we get into issues like
\"well when will w3c address my xxx format\", but I think
format-specific accessibility issues  and techniques for addressing
those issues are complex enough to warrent being addressed separately.
 There might also be a more general introductory document that tries
to unify things a bit by highlighting the general accessibility issues
common among all formats.

Breaking things down by disability might be useful, but again thorny
issues arise like \"why hasn\'t the w3c addressed the needs of people
with xxx disability\".  Realistically, however, most accessibility
issues relate to people with vision and hearing loss. Many solutions
which address people with these disabilities will also address the
needs of people with mobility impairments (input device independence).
 People with learning disabilities can also bennefit from guidelines
not explicitly written for that group: if pages can be used via screen
reader, then other intermediary software could use the same
information to present the document in a way more conducive to folks
with LD.  In effect, making something usable by someone using a screen
reader means that it is written in such a way that a software entity
(in this case, a screen reader) can act as an intermediary in a way
that preserves all the ritchness and semantics of the original
document. If this is true, then we should be able to replace the
screen reader with another software agent aimed at helping LD folks.

Again, the points here are that the spec is too bloated and complex
because its scope is too wide. Any kind of modularization, either as
outlined above, or by breaking it down some other way, is good.

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

We agree with the need to simplify the guidelines and have taken
extensive steps to do so.  Some of these include:

Easier language to understand
- Wrote simpler guidelines
- Removed as many technical terms (jargon) as possible replacing them
with plainer language or, where possible, their definitions
- Eliminated several new or unfamiliar terms. (authored unit, etc.)
- Removed the term Baseline and replaced it with "web technologies
that are accessibility supported" and then defined what it means to be
accessibility supported.
- Removed the nesting of definitions where we could (i.e. definitions
that pointed to other definitions)
- Tried to word things in manners that are more understandable to
different levels of Web expertise
- Added short names/handles on each success criterion to make them
easier to find and compare etc.
- Simplified the conformance

Shortening the document overall
- Shortened the introduction
- Moved much of the discussion out of the guidelines and put it in the
Understanding WCAG 2.0 document
- Shortened the conformance section and moved it after the guidelines
- Moved mapping from WCAG 1 to a separate support document (so it can
be updated more easily)

Creating a Quick Practitioner-oriented Summary / Checklist-like document
- Created a Quick Reference document that has just the Guidelines,
success criteria and the techniques for meeting the success criteria.
With regard to creating a separate set of guidelines for different
disabilities, we don't think that would be effective.   Web authors
have enough trouble without having to consult multiple documents in
order to create one accessible site for people with disabilities.

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