W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2001

Re: Disability Type Analysis of WCAG 1.0

From: Charles F. Munat <chas@munat.com>
Date: Fri, 24 Aug 2001 12:32:44 -0700
To: "WAI Guidelines WG" <w3c-wai-gl@w3.org>
Message-ID: <LHEGJAOEDCOFFBGFAPKBOEEECJAA.chas@munat.com>
This is a response to a post to the IG list. I am reposting (not
crossposting) it here because it affects us. If you aren't on the IG list,
you may wish to read the original post, quoted at the bottom of this
message.
---------

The problem with this sort of uncontrolled study is that it usually produces
results which have no bearing on reality. Experiment design is difficult,
and even the best scientists often discover too late that they have
forgotten to account for some variable.

There are many possible explanations for Kynn's results other than a bias
("trend" is a euphemism) in the WCAG. The most obvious is that Kynn may have
simply assigned checkpoints to categories of disability incorrectly. (Note:
I am referring here to a bias in the document, not in the people who created
that document.)

Assuming that Kynn got the split right, it is still possible (even likely)
that the difference is the result of differences in specificity. For
example, the 14 Aug 2001 draft of WCAG 2.0 specifies: Write as clearly and
simply as is possible and appropriate for the site's content. (checkpoint
3.3)

This could be broken out into more specific checkpoints:

1. Use commonly understood words.
2. If a word is not commonly understood, provide a definition.
3. Expand acronyms.
4. Use simple sentence structures.
5. Use examples.
6. Organize ideas into forms that make relationships between ideas clear.
7. Etc.

Assuming that these checkpoints are considered "cognitive disability"
checkpoints (a problem in itself since following the above will benefit
everyone), suddenly we've shifted the balance considerably without really
changing the content. A similar effect can be produced by reducing the
specificity of, say, blindness-related checkpoints.

In fact, that is what has occurred between WCAG 1 and WCAG 2. Checkpoints
are becoming more generic, less specific. This alone may account for the
apparent shift away from a bias toward blind and deaf users. I am currently
working on a new version of checkpoint 1.3 which would subsume 1.4. This
appears to further shift the balance, whereas in reality it is only a change
in wording.

Another possible explanation for Kynn's results is that the WCAG 1 was more
about code than content. This had nothing to do with specific disabilities,
it had to do with who was creating the guidelines: mostly programmers.
Programmers tend to think in terms of code. Therefore, most of the solutions
proposed had to do with code. Content was an afterthought. So if this is
true, it is not a matter of bias toward one or another disability, but of
bias toward code-related solutions. Code-based solutions tend to help users
who have trouble *getting to* the information. Content-based solutions tend
to help users who have trouble *comprehending* information.

There are plenty of other reasons why the numbers could come up the way
Kynn's did. I won't bore readers with more examples.

So what does this mean? It means that Kynn's experiment tells us NOTHING. We
can't use these results because we haven't designed the experiment properly,
and there may be serious problems with our results. If we depend on these
results in any way, we could be making a big error.

But the biggest problem with this sort of informal experiment is that it may
fool us into thinking that we DO know something. And that may send us off in
directions that do nothing to improve the guidelines. Ask yourself, aren't
you tempted to believe that the apparent bias toward some disabilities means
something? It's hard NOT to be affected by these sorts of results.

Worse, this sort of experiment gives support to partisanism. Those who would
advocate for only one group can use this to bash anyone who doesn't toe the
party line. Results like these give rise to "See, I told you so!" comments
and worse.

Here is what I recommend:

Instead of looking for bias in the WCAG, why don't we look for needs that
haven't been addressed? Has it occurred to anyone that it might take more
checkpoints to address the needs of one group than it does another? (Kynn
acknowledges this in his comments about photo-epileptics.) Who cares how
many checkpoints address this group or that group? This isn't a contest to
see whose is longer.

The real question is HAVE WE FAILED TO ADDRESS ANY NEEDS? If we have, then
please state the specific problem, and, if possible, some solutions.
SOLUTIONS ALONE DON'T CUT IT. It is not enough to say, We need more
pictures! We need to know why. Instead:

1. Name the specific disability or disabilities.
2. Describe how access is impaired or denied to persons with these
disabilities.
3. Suggest a solution.
4. Describe how this solution improves access for these persons.

You may also want to:

5. Mention any problems with implementation (such as cost, lack of
supporting technology, etc.)
6. Mention any potential conflicts with other checkpoints/techniques.

If the current WCAG 1/WCAG 2 draft do not fully address the needs of one or
more groups of people, then we need to know WHAT needs aren't being
addressed and HOW this problem can be rectified. If the WCAG 1/2 DO address
the needs of all users, then what difference does it make how many
checkpoints were needed to accomplish this?

Chas. Munat
Received on Friday, 24 August 2001 15:30:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:12 GMT