Your comments on WCAG 2.0 Last Call Draft of April 2006

Dear  P.J. Gardner ,

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/002801c6964d$479bd140$6401a8c0@D2K2GT91
(Issue ID: LC-1312)WAI WCAG 2.0 Working Group:

In an e-mail dated 26 May 2006, called "Extending Deadline on WCAG 2.0 Last
Call Review", Judy Brewer said:

"I encourage you to read the guidelines while they are in Last Call Working
Draft; evaluate them against your own needs and
expectations; then share with the Working Group your comments on what you
think needs to change in the document."

I want to add my voice to the chorus of people responding to the Last Call
Working Draft.  I already participated as one of the chief authors in a
subcommittee of the AccessAbility SIG of the Society for Technical
Communication that submitted a response earlier today
(http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/), but I
also wanted to add some personal notes as a Web Accessibility advocate and
an independent accessible web designer.

I am founder of Boston-IA, a networking organization for web developers, web
authors, and other internet professionals to teach them about accessibility
and advocate to make the web a more accessible place.  I am program director
to bring Knowbility's Accessible Internet Rally (AIR) program to Boston in
2007 to teach individual web developers how to build accessible web sites
for non-profit organizations.  I am a web accessibility consultant, and I
build accessible web sites for small (very small) businesses and non-profit
organizations with small budgets.  I am a career technical communications
professional, I consult with greater Boston businesses in web design and
information architecture, and I am a member of the STC AccessAbility SIG.  I
have a graduate certificate in Accessible Web Design from Northeastern
University.

I know how to build an accessible web site, and I understand the new
technologies that we will be struggling with over the next few years.  But I
think the new WCAG will not help me advocate for accessibility, assess web
sites for accessibility, train people in accessibility, or teach me, any
more than I learned from WCAG 1.0, how to build accessible web sites or how
to consult with the companies who ask me to help them meet accessibility
standards.

I think that much of the emphasis of the latest draft of the WCAG 2.0 is
focused on the web development efforts of very large corporations and on the
applications that are being developed under the latest technologies.  I want
to focus again on the people in the trenches who often perform the work of
accessibility on their own.  While the attention of larger organizations may
be focused on accessibility compliance (conformance in WCAG 2.0 language)
because of increasing business pressures, the focus of the small accessible
web developer is on accessibility adherence.  Many of us already want to
make web sites accessible, and we need help spreading the word to fellow
standards-based coders.

Independents are looking to the Web Accessibility Initiative and the Web
Content Accessibility Guidelines for guidance, but our needs as developers
are being lost in the shuffle with the new document.  This surprises me,
given the large number of members of the International Webmaster
Association/Help Writers Guild (of which I am also a member) in the Working
Group.

The documents are so cumbersome, and the problems are so firmly entrenched
in the current approach, that my comments about individual items in the
basic WCAG 2.0 document will be hard to communicate quickly, although I will
try to address them in separate e-mails about the individual documents that
support the rather slim WCAG 2.0 (which is really just a table of
contents)--one at a time.  But the basic approach is flawed, and we cannot
make the documents more usable for the independent web developer without a
major redesign.

Please keep in mind the solo web developer, the independent web
accessibility consultant, the people in small web design firms, and in a
non-profit organizations or educational institutions that may want to meet
accessibility standards but have no budget to undertake months-long
accessibility initiatives.  This group needs very basic guidance about how
to build accessible web sites, not guidance on how to comply or how to
establish baseline statements.  We need support to keep convincing people
that web accessibility is worth undertaking, even without a big budget or a
huge staff.

Please help us make the World Wide Web more accessible than it is today.

Best Regards,
P.J.

.............................................
P.J. Gardner
Web Accessibility Consultant

Gardner Information Design, Inc. (www.gidi.biz)
Boston-IA (www.boston-ia.org)
AIR-Boston (www.knowbility.org/air-boston)
.............................................
----------------------------
Response from Working Group:
----------------------------It is indeed hard to make a technical
reference and a practical user guide in the same doc.  Also one for
advance technologies that are now appearing on the web and one that
works for the bulk of the basic bread and butter web developers.

In the new draft, we have tried to make it much easier to read and
understand.  We also created a Quick Reference doc that pulls together
what developers need most (the basic requirements and the practical
techniques for meeting them).

Some other things we have done include:

Addressing users with different expertise levels
- Tried to create language that is simpler to understand but also
includes the technical background for those who want to delve into the
technical underpinnings.

Testability
- tightening up testability, identifying tools for key hard to measure
areas, and having tests for all documented techniques cited as
sufficient

Easier language to understand
- Writing simpler guidelines
- Removing as many technical terms (jargon) as possible replacing them
with plainer language or, where possible, their definitions
- Eliminating several new or unfamiliar terms.  (authored unit, etc.)
- Removing the term Baseline and replacing it with   "web technologies
that are accessibility supported"  and then defining what it means to
be accessibility supported.
- Removing the nesting of definitions where we could (i.e. definitions
that pointed to other definitions)
- 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

Shortening the document overall
- Shortening the introduction
- Moving much of the discussion out of the guidelines and into the
Understanding WCAG 2.0 document
- Shortening the conformance section and moving it after the guidelines
- 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 Practitioner-oriented Summary / Checklist-like document
-  Creating a Quick Reference document that has just the Guidelines,
success criteria and the techniques for meeting the success criteria.

Let us know if the better meets your needs and those of your colleagues.

Received on Thursday, 17 May 2007 23:25:10 UTC