RE: Disability Type Analysis of WCAG 1.0

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?

Just my two cents.

Charles F. Munat
Seattle, Washington



> -----Original Message-----
> From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org]On
> Behalf Of Kynn Bartlett
> Sent: Friday, August 24, 2001 5:20 AM
> To: w3c-wai-ig@w3.org
> Subject: Disability Type Analysis of WCAG 1.0
>
>
>
> On a thread on the WCAG working group mailing list, I raised the issue of
> the state of Texas interpreting WCAG 1.0 as being guidelines for access
> by people with visual disabilities (thread:
> http://lists.w3.org/Archives/Public/w3c-wai-gl/2001JulSep/0664.html
> Texas policy: http://www.dir.state.tx.us/standards/S201-12.htm).
>
> The concern is that needs of people with disabilities who are _not_
> blind may be forgotten by those making policies or interpreting the
> WCAG guidelines.
>
> But it also raises an intriguing question -- are the guidelines slanted
> toward championing the needs of certain disability types over other
> types of disabilities?  (Yes, I know some of you believe this already,
> hi Anne.)
>
> So I did number crunching.  Here's my methology:
>
> 1.  I made an spreadsheet and listed each WCAG 1.0 checkpoint.
> 2.  I made one column for each of several broad disability types:
>      (a) Blind (defined: unable to see visual information)
>      (b) Color-Blind (defined: unable to reliably distinguish colors)
>      (c) Limited Vision (defined: can see but not well; may need
>          large fonts or magnifiers)
>      (d) Deaf (or hard of hearing; defined: cannot hear sounds reliably)
>      (e) Low Dexterity (defined: unable to use a pointing device
> and instead
>          must use keyboard or switch)
>      (f) Low Comprehension (defined: having problems understanding
>          content, textual or otherwise)
>      (g) Low Reading (defined: having problems reading text)
>      (h) Epilepsy (defined: may be subject to epileptic episodes)
> 3.  I went through each checkpoint and recorded whether or not the
>      checkpoint applied to that disability type.
> 4.  Some checkpoints were listed as "all", while others were listed as
>      "did not clearly apply to specific disabilities."
> 5.  Sums and percentages were produced.
>
> (Obviously, there is much potential in error in the above; for example,
> you could choose to use different disability types (or definitions), or
> you could assign applicability in different ways.  If you are doubtful
> of my figures, I urge you to try the analysis yourself to see what
> numbers you might get.)
>
> Here are my findings on WCAG 1.0:
>
>    Blind: 70.8%
>    Color Blind: 10.8%
>    Low Vision: 23.1%
>
>    Deaf: 9.2%
>
>    Low Dexterity: 20%
>
>    Low Comprehension: 24.6%
>    Low Reading Skills: 21.5%
>
>    Epilepsy: 7.7%
>
>    N/A: 10.8%
>
> This tends to show a trend -- "bias" is a loaded word -- supporting
> the idea that visually impaired users are highly promoted within WCAG
> 1.0.  One of the reasons for this is that access by people with visual
> disabilities is relatively well-understood and there is a long history
> of activism on web to promote those interests.  It's also attributable
> to the fact that much of the assistive technology used on the web for
> output is designed for people with visuam impairments.  (AT used for
> _input_ is more common among people with dexterity limitation.)
>
> Now, something more interesting to look at is the priority system of
> WCAG 1.0.  Here's how that breaks down:
>
> Priority One:
>
>    Blind: 81.25%
>    Color Blind: 18.75%
>    Low Vision: 25%
>
>    Deaf: 25%
>
>    Low Dexterity: 12.5%
>
>    Low Comprehension: 12.5%
>    Low Reading Skills: 18.75%
>
>    Epilepsy: 12.5%
>
>    N/A: 0%
>
> Priority Two:
>
>    Blind: 63.3%
>    Color Blind: 10%
>    Low Vision: 30%
>
>    Deaf: 3.3%
>
>    Low Dexterity: 16.7%
>
>    Low Comprehension: 26.7%
>    Low Reading Skills: 16.7%
>
>    Epilepsy: 6.7%
>
>    N/A: 13.3%
>
> Priority Three:
>
>    Blind: 73.7%
>    Color Blind: 5.3%
>    Low Vision: 10.5%
>
>    Deaf: 5.3%
>
>    Low Dexterity: 31.6%
>
>    Low Comprehension: 31.6%
>    Low Reading Skills: 31.6%
>
>    Epilepsy: 0%
>
>    N/A: 15.8%
>
> It's interesting to note the distribution here -- it implies that if
> you choose only "single-A" accessibility, you are primarily meeting
> needs of blind users, while "double-A" provides a broader range, and
> "triple-A" an even wider cross-section especially among people with
> limited input ability and cognitive impairments.
>
> Why is this?  (As a diversion:  It's NOT because people on the working
> group are biased.)  Most likely it is because blindness issues are,
> for lack of a better term, more "black and white".  They are either "do
> or do not, there is no try."
>
> On the other hand, the types of considerations you need to make for
> different audiences tend to be more vague, and really -are- of the sort
> "try to do this" or "do as much as you can" or "make it better by doing
> some of this."
>
> Because of the way the WCAG 1.0 priority system is structured, this
> promotes the needs of users who fit a "do or do not" scheme over the
> needs of those users who fit a "try" scheme.  This explains in part why
> some disability types seem to be "more important" in WCAG 1.0.
>
> Here is another set of numbers:  These are the percentages of different
> priority levels, for checkpoints which apply to each disability type.
>
> Blind:
>    Priority 1: 28.3%
>    Priority 2: 41.3%
>    Priority 3: 30.4%
>
> Color Blind:
>    Priority 1: 42.9%
>    Priority 2: 42.9%
>    Priority 3: 14.3%
>
> Low Vision:
>    Priority 1: 26.7%
>    Priority 2: 60%
>    Priority 3: 13.3%
>
> Deaf:
>    Priority 1: 66.7%
>    Priority 2: 16.7%
>    Priority 3: 16.7%
>
> Low Dexterity:
>    Priority 1: 15.4%
>    Priority 2: 38.5%
>    Priority 3: 46.1%
>
> Low Comprehension:
>    Priority 1: 12.5%
>    Priority 2: 50%
>    Priority 3: 37.5%
>
> Low Reading Skills:
>    Priority 1: 21.4%
>    Priority 2: 35.7%
>    Priority 3: 42.9%
>
> Epilepsy:
>    Priority 1: 40%
>    Priority 2: 40%
>    Priority 3: 20%
>
>
> I hope this is informative and thought-provoking; my goals here are to
> examine how things look and figure out why, and whether or not this is
> something that needs to be considered as we work on future versions of
> guidelines.  Please note:  THIS IS NOT AN INVITATION TO START DISABILITY
> VS. DISABILITY FLAMEWARS.  We are all on the same team here, even if we
> represent different types of audiences, so let's not assume any malice
> is at work in the way WCAG 1.0 was written.
>
> --Kynn
>
> --
> Kynn Bartlett <kynn@reef.com>
> Technical Developer Liaison
> Reef North America
> Accessibility - W3C - Integrator Network
> ________________________________________
> BUSINESS IS DYNAMIC. TAKE CONTROL.
> ________________________________________
> http://www.reef.com
>
>

Received on Friday, 24 August 2001 15:30:33 UTC