Re: Requirement for Disability-based Checkpoint Identification

At 02:04 AM 2000-10-09 -0700, kynn@idyllmtn.com wrote:
>
>The requirements document makes a mention of a mapping of checkpoints
>to disability groups in WCAG 2.0.  This might be a good project to start
>on.  We will, of course, need to identify the disability groups first!
>Anyone got a decent, comprehensive, sensitive list?
>

There are some fine lines you have stepped across in that re-statement of what
should be done, that make the job to be done harder than it has to be.  And
more impolitic.

The idea that you have to identify the list of groups first is widely assumed,
but actually a bad idea.  What is easy to do objectively is to analyze and
find
out what human function was involved in the functional breakdown.  The
description of the functional dependency that failed in this analysis does not
need to use standard terms for the function, just describe clearly what the
Web
content assumed could be done and actually couldn't.  The grouping of those
functions is something where we should follow the best practice we can find
that somebody with a broader base has agreed on.  And it is not necessary to
have that selected before we do what we actually need to do.

The web is a man-machine system.  Web browsing is a closed-loop continuing
process where both the human and computer have to do things in each cycle.  If
the process is critically dependent on something the human can't do, or do
well, there is a breakdown in the cycling.  The disability is composed of a)
critical dependency on a particular function and b) functional impairment in
the person.

What the WAI can do without fear of contradiction is failure mode analysis on
the failures.  This can identify the human function in un-controlled
vocabulary, whatever seems clear.  Be over-specific.  This is really what the
guidelines need, anyway; traceability to where there is actual damage.  The
sort of thing required for a case to have standing to be heard in court.  As a
post-pass one can catalog the functional impairments according to a controlled
vocabulary.

Deciding where one group starts and the next one stops is hard.  The taxonomy
used by the U.S. Census is a good starting point, however.  There may be a
U.N.
or other international NGO equivalent to this.

But most emphatically, you do _not_ need a controlled vocabulary of disability
categories as a precondition to doing the "trace to actual damage scenarios"
work that is what the guidelines need.

First you need facts.  Then you can worry about how well the facts are
represented in the existing standard vocabulary, and even introduce a few new
terms if, after careful review, the available 'controlled vocabulary'
terminology fails to make what we have to say clear.

Al

PS:  Sorry, but this is a sore point with me.  Definitions are overrated.  We
need explanations.  Definitions are explanations with some added business
rules
around them.  But we used to need definitions more in the Gutenberg era
than we
do today, and we are trying to solve tomorrow's problems with our minds
reflexively applying yesterday's business rules, and it is holding us back.

PPS:  In migrating the topic language from 'mapping' to 'identification' you
have slipped in a difference that is also, if one is observing nice
distinctions in the spec-for-spec language, unfortunate.  We need traceability
from the guideline to illustrative concrete actual-damage scenarios.  But this
need not be exhaustive or definitive.  So the disability connection is not
required to be suitable for the 'identification' of the guidelines. 
Clarifying, representative examples are required.  Not a definitive statement
of the boundaries of those affected.  So, we need the relation-trace, the
mapping.  But it is probably better if this relation is not employed as the
'identification' of the guideline.  Putting the category names up front in any
sort of naming role would be more divisive than putting the concrete cases on
the back side by way of explanation.

Part of the deal is keeping the injured groups convinced that it is in their
interest to join hands in unanimously demanding universal design.  Not a
trivial job, as you may have noticed.

So, let the guidelines be identified by how it relates to the content, and be
justified by the scenario where violation damages the functionally-impaired
user.  Don't identify [label] the rule by "this is for blind, this for halt,
this for lame, ...."  That is where we can't go and sustain our
coalition-building efforts.

>--Kynn
>
>PS:  This is a good case for separating out "textual equivalents" into
>     more than one checkpoint.
>

Received on Monday, 9 October 2000 11:43:18 UTC