Re: Requirement for Disability-based Checkpoint Identification

Al,

	I agree with your comments about identifying "disabilities" by what a
person cannot do, not by their medical/psychological label. In the case of
the learning disabled, the range of disabilities is so wide that some LD
folks are benefitted by what helps the visually impaired, some by what
helps the hearing impaired, some by what helps those with physical
disabilities, and those with cognitive disabilities. A mix isn't unusual in
an individual. I suspect this is frequently true in other "labeled"
categories. Years ago I taught a severely visually impaired girl who was
also moderately retarded and extremely sensitive (negatively) to auditory
input designed for the blind. I'm sure there are other folks whose
disabilities make web solutions difficult if you're just accommodating by
labels. 

I'd suggest classification by preferred modality: visual (graphic and
text), auditory (speech and natural and/or music), and outputted to screen,
sound card, or printer (textual (braille) ... or visual)... and whatever
braille output panels may come in the future) ... 

What have I left out?

				Anne


 

			

At 12:06 PM 10/9/00 -0400, Al Gilman wrote:
>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.
>>  
>
>
Anne L. Pemberton
http://www.pen.k12.va.us/Pav/Academy1
http://www.erols.com/stevepem/Homeschooling
apembert@crosslink.net
Enabling Support Foundation
http://www.enabling.org

Received on Monday, 9 October 2000 18:10:00 UTC