This essay was originally posted to the Web Accessibility Initiative interest group mailing list.
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:
(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:
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:
This information and the previous table which covers all of WCAG are summarized by Figure 1:
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.
Another thing to add is that certain disability types may have "simpler needs" than others, or have needs which can be expressed in fewer check- points. Such as users with epilepsy, where the principle seems to be "don't trigger episodes by using strobing." But it may not be sufficient, for web design purposes, to merely summarize access by visually impaired users with "don't rely on visual content alone." Thus these numbers should be taken with a grain of salt.
Here is another set of numbers: These are the percentages of different priority levels, for checkpoints which apply to each disability type.
This information is depicted graphically in Figure 2. (Note that actual checkpoint counts are presented below, not percentages as above..
Now, let's take a look at the still-in-development WCAG 2.0, and then at the U.S. federal government's Section 508 requirements.
Here is a look at the current working draft of WCAG 2.0 (working group draft, 14 August 2001):
Let's compare those with WCAG 1.0:
This is rather encouraging -- it shows a move toward checkpoints which tend to be more universally applicable and a promising increase in representation for a number of disability types. It also represents a simplification trend, reducing the number of checkpoints considerably (which increases the need to make each checkpoint broader).
So, WCAG 2.0 looks like a step forward for making accessibility guidelines which "look like the web". (Meaning: Closer to a more inclusive document than before.)
I'm not sure if the same can be said for the Section 508 requirements, though. Let's look at those:
Comparing this with WCAG 1.0 "priority one":
Section 508 seems to have mostly adopted the requirements for visual disabilities from WCAG "single-A", but falls behind on cognitive limtations. This is mostly attributable to the fact that WCAG 1.0's "use clearest and simplest language" checkpoint which does not have an equivalent in 508. Some progress seems to have been made for low dexterity but that is a bit misleading since keyboard access is not explicitly required in 508.
508 "looks like the web" less than WCAG 2.0.
It's also worth comparing 508 with all of WCAG 1.0, not just the priority one checkpoints; WCAG 1.0 is quoted above (in comparison to WCAG 2.0) and I think this illustrates the danger of policy makers merely assuming that following most or all of the "priority one" checkpoints will allow you to meet the needs of a broad audience. *This is not true.* To meet the needs of a wide audience of people with disabilities, you -must- take many of the actions which WCAG 1.0 rates as priority two or priority three.
Figure Three graphs the comparison between WCAG 1.0, WCAG 2.0 draft, and Section 508.
Copyright © 2001 by Kynn Bartlett. Permission is granted by the author for this essay and graphs to be posted on the ICDRI site. All rights are reserved by the author. For reprint permission please contact via email.
Copyright © 1998