RE: Disability Type Analysis of WCAG 1.0

Kynn Bartlett wrote:
> People who have read the
> guidelines have come away thinking that they're all about access for
> blind people, and all about access by screenreaders.  This is not just
> a hypothetical case, or even anecdotal; you can find solid evidence which
> says folks think "WCAG 1.0 is about blind people, or about blind people
> primarily."

True. But we didn't need to count the checkpoints to learn that. The Web
being primarily a visual medium, it is only natural that it will present
more problems for blind users than for others. If you want to do a count,
how about this one:

What percentage of sites are inaccessible to blind users?
What percentage of sites are inaccessible to deaf users?
What percentage of sites are inaccessible to people with motor impairments?
What percentage of sites are inaccessible to people with cognitive
disabilities?

And you can break it down more specifically if you like.

My guess is that if you did such a survey you'd find that most of the
accessibility problems on the Web are blindness related. These problem are
also the simplest to solve, and they involve code more than content.

It is perfectly understandable that people might think that accessibility is
all about making sites usable by the blind. But we already know that some
people think this, we don't need to start a checkpoint war to correct it, we
need to educate users. Pointing out that there are more checkpoints
concerned with accessibility to people with visual disabilities only
distracts from the real issue, which is *are there any accessibility needs
that we have failed to meet*? If no, then it is a simple matter of
education, of doing exactly the opposite of what this "study" does: pointing
out the checkpoints that address needs other than those of blind users.


> And just the same, it's hard not to read WCAG 1.0, which spends about
> 75% of the guideline space dealing with blindness issues, and not come
> to the conclusion that accessibility is mainly about blind people.

But this ignores the possibility that 75% is appropriate. The question, as
I've mentioned several times already, is Are there needs that aren't being
addressed? If all needs have been addressed, then we simply need to educate
users. That can be accomplished in the introduction to the Guidelines. If
not all needs have been addressed, then what are the needs and how do we
address them? Specifics will get something done. Rushing about trying to
balance the number of checkpoints without regard for whether needs have been
addressed is a waste of time. (I'm not suggesting that Kynn advocates this,
only that it is a danger of this sort of "study.")

> See, it all actually does make sense -- the study of "how much column
> space is spent on <x>" can let us know whether or not people who read
> WCAG incorrectly are doing it because they're "just stupid or something"
> and "didn't read carefully"; or, if perhaps when WCAG was written, the
> authors didn't realize that the amount of space spent primarily on
> screenreaders and blind people would lead to a lot of misinterpretation.

But you didn't look at how much column space was spent on blind user issues,
you looked at the number of checkpoints. Checkpoints address specific
problems. There should be as many or as few checkpoints as it takes to
address that problem, regardless of what people think. Where column inches
come into play is in the *Introduction*, and that is where we should be
focusing our attention. But we didn't need to count checkpoints to do this.
We could have simply said, "People appear to be getting the idea that the
Guidelines are all about helping blind people. We need to rewrite our
introduction to stress access for people with other disabilities as well."
Thus we could have accomplished the same thing, and avoided subjective
surveys that may create problems from credibility issues to outright
checkpoint wars. By doing such a survey, we imply that it *does* have
meaning, that the number of checkpoints per disability tells us something
when, absent controls, it tells us nothing more than the number of
checkpoints that address each disability. Frankly, this is useless
information unless you presume that such information *means* something
beyond the number itself. And that is where the danger lies.


> I think there's a value in examining not only WHAT we wrote, but how
> we wrote it.  You gave an example of splitting a "write clearly"
> checkpoint into a half dozen, to elevate the importance of one group's
> needs -- I think we need to consider whether or not that kind of
> thing was (unconsciously) done before, producing an artificial
> _apparent focus_ on one group.

I don't think we need to examine that at all. I think we need to examine
whether checkpoints are overly specific or overly general, and I think
that's exactly what we're doing with WCAG 2. I personally think that
Guideline 3 needs a serious rewrite (and I'm putting together a suggestion).
I also think that Guideline 1 can be simplified considerably (ditto). I
haven't even looked at Guidelines 2 and 4 yet. But the question shouldn't be
who gets how many checkpoints; it should be, Have we achieved the right
level of specificity?

Chas. Munat

Received on Saturday, 25 August 2001 14:54:30 UTC