Your comments on WCAG 2.0 Last Call Draft of April 2006

Dear Andrew Harris ,

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/20060526061658.A6E7633205@kearny.w3.org
(Issue ID: LC-648)

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

Thoroughly disappointed and disillusioned with WCAG 2.

I had hoped all the \'problems\' would be ironed out by this stage,
but it seems that they have just become more ingrained.

To be fair, I can see where you\'re heading - that being specific
about things like current technologies runs the risk of being outdated
in the near future. I can see why you are using abstracted terms like
\'Baseline\' and not further emphasising Validation, but in practice
it is not going to work.

Why?

One of the biggest problems I had with WCAG 1 was the non-measurable
stuff. You could run your page through a software checker and it would
return some results, but others you had to \'interpret\'. It took a
lot of training and practice to get people to understand what these
guidelines meant. Most found it too hard. Consequently, the vast
majority of people/companies think accessibility is simply \'alt\'
text for images.

What the accessibility world is really crying out for is a measurable,
detectable, practical standard. One that can be used in day to day
work without a great deal of knowledge or training.

WCAG 2 seems to have gone in the other direction. Introducing more
jargon, less certainty, more difficulty... it is not going to work.

Baseline

As an example, the idea of a Baseline has merit. In a perfect world,
it would probably work, technologies would be designed up to
acceptable standards and companies would work to improve those
standards. In reality, this is rubbish. Without a hurdle, no-one will
spend money to achieve a reasonable level of accessibility unless they
are forced to do it. You cannot leave the \'stating of baselines\'
totally in the hands of the provider, or there will be no incentive to
improve. Quite apart from that, setting a baseline will require a
level of expertise that most providers simply do not have and probably
do not wish to acquire.

If you are wedded to the idea of baselines, then the only way it will
work in the \'real\' world is if you set \'minimum baselines\' in
those media and channels for which there are w3 or other accessible
standards. This would ensure that there is always a point of reference
to turn to. These \'minimums\' might be documents separate from WCAG,
so needn\'t compromise its longevity, but could be easier to update as
technologies change - in fact, improving the relevance of WCAG 2 over
time.

Validity

As a trainer and advocate in my workplace for webstandards and
accessibility, one of the most effective tools in aiding understanding
is the online validator. The W3 HTML validator or accessibility
\'checkers\' like  Bobby or \"Cynthia Says\"... it doesn\'t matter,
the user checks their page and gets some feedback about obvious
problems. Of course if a page is not valid code, it often can\'t be
checked, so one of the most valuable and visible checks on a page is
rendered useless.

As I understand it, Valid Code is not recieving the emphasis I believe
it should. There are provisions for validating \'Web Units\', but some
uncertainty about whether these will be regarded as \'essential\' to
any overall level of success.

I always tell people that a valid page is a big first step towards an
accessible page, in fact, I think it is essential and should
definitely be right up there as a priority 1 checkpoint - or whatever
they\'re called now ;-) Validity is measurable, and helps create
semantic, well structured data. Make it a minimum!

Proposed Change:

1) Consider publishing accompanying baseline documents to ensure there
is a clear, measureable expectation for levels of conformance.

2) Increase the emphasis of validation to
published/accepted/measurable standards

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

Regarding measurability and detectability:
At http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-sc, WCAG now
states: "All WCAG 2.0 success criteria are written to be testable.
While some can be tested by computer programs, others require human
testers for part or all of the test. The same results should be
obtained with a high level of confidence when people who understand
how people with different types of disabilities use the Web test the
same content."

Regarding Baseline issues:
The term "baseline" has been replaced by "accessibility-supported web
technologies".  The guidelines and success criteria remain
technology-independent, in order to allow conformance using any Web
technology but that technology must be supported by user agents,
including assistive technologies. So, in choosing Web technologies
that will be used when creating content, authors must use technologies
that will work with existing user agents, including assistive
technologies, that are available to the users of their content who
have disabilities.

To make it easier for authors who may not be familiar with or have
"expertise" of assistive technologies, and to take the responsibility
out of  "the hands of the provider", documented lists of
accessibility-supported web technologies will be developed by WAI and
other sources.

Regarding Validity: The working group charter designates the inclusion
of issues that directly affect accessibility.  While some aspects of
"use technologies according to specification" do relate to
accessibility, others do not.  The aspects that do relate are covered
in other success criteria in the Guidelines. Requiring validation to
published/accepted/measurable standards would go beyond accessibility.
Note that we encourage validity and list it first in the sufficient
techniques for meeting this success criterion.

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