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 08:26:54 UTC