W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2001

two birds with one stone, focus, and organization

From: Al Gilman <asgilman@iamdigex.net>
Date: Fri, 07 Sep 2001 18:35:43 -0400
Message-Id: <Version.32.20010828102443.04127d20@pop.iamdigex.net>
To: w3c-wai-gl@w3.org

As I re-visited Bill's visual summary of the WCAG at


I began to get an idea.  The idea started as "you can't separate the treatment
of media diversity and expository mode diversity under major sections for
presentation and comprehension, because the remedies are the same."

The content provider isn't supposed to provide equivalent alternatives
addressing sensory barriers, and then different equivalent alternatives
addressing cognitive barriers.  You want to leap as many of the phase
boundaries in "what mode works" as you can with the minimum redundancy in
of parallel data.

_Any text_ synchronized with video supports search and recovery.  It doesn't
matter if it is caption or transcript.  _Any non-text_ aids the reading
impaired, whether it is graphics, reading the text, styling motifs or sonicons
(mouse-over leitMotifs, for example).

The bottom line image is that our product is techniques.  It is a response to
'how.'  What we offer is how to cover the diversity of disability needs with
the minimum of wasted effort and the maximum gain (in usability by all) for
your pains.  It's _Web_ content accessibility knowledge, a domain that is
scoped or bound in the technology dimension.  It is the marriage of user needs
and technological capabilities.  We can generalize and raise the level of
abstraction with regard to these techniques.  But the techniques are the
product.  Until we make the connection with the technology, all we have
provided is motivation, is heuristics.  Our first job is to be informative as
to what techniques work.  We can worry at our leisure how and who shold make
what normative thereafter, if we are doing Our Job which is that.  
One of the top level strategies is this business of hitting two birds with one
stone.  Let one split into redundant expositions of an idea serve more than
access failure repair.  This is a message that can't be left to a subsequent
commentary.  That is major business between us and our customers.

Sorting what we have to say by function that gets impaired and then
repaired is
one axis of the plot.  But the technological resources to synthesize the web
content are another equally important dimension of the plot.  We are helping
people build bridges between these two edges of the chasm.

Redundancy is a major strategy.  There is a user-derived requirement that the
redundancy span the critical divides, the "phase boundaries" of content
usability.  Although some of the failures arise in sensory functions in the
user, and others arise in failures deeper in the processing, the response is
clear.  Reiterate in different ways.  Show and tell.  Text and image.  The
details of what gotchas to avoid in user disability and the details of how to
indicate this in SVG vs. VoiceXML are equally subordinate details.  Not the
major categories we are talking about.

On the technology side, there is the requirement that the linkages between
equivalents or feasible alternatives be machine comprehensible, so that user
agents can implement systematic and easy to use methods of content control
get the actual usage in the configured delivery context to be something that
the user can and wants to use.

The diversity requirement on the content is a both and of crossing the phase
boundaries in Person With a Disability usability, and the formal semantics
requirement of User Agent machine recognizability and operability (in content
control, see UAAG 2.3).

Kelly's remark helped to pull this into focus, too.  Our number one enemy on
the Web today is not missing ALT text but inscrutable form controls.

This fits into our mandate as follows:

General HCI principle:

- Classic version:  The system response to user input should be predictable.
- QuickTips version:  Let the user know what they can do.

That's above the level of the WAI problem but we need to point out the
traceability to that general principle.  Our contribution is how to satisfy
this guideline in the presence of disabilities.

Web major subcategories of the above:

+ Form controls
+ Hyperlink navigation
+ Navigation within the page

Web techniques for these:
+ text labels
+ intrapage structure and containers
+ link text front-loaded, diversified in initial letter (see list of links
+ icons
+ mode switches
+ alternate sites 
+ content negotiation
+ Mention non-Web options for equivalent service (800 numbers, email, etc.)
+ etc.

So we set the context in terms of a major HCI principle and major Web
functions.  Then we get down to surveying the failure modes, the technology
resources, and the known good techniques.  Job done.

In other words, the outline should follow a general outline for web content
design, without regard to disability, and the disability particulars should
enter as an inner, not an outer, loop variable.

That would be something interesting to try.  We can talk about this more in
discussion of who does what about what parts of the answer concerning the
XMLGL.  We realized too late in the development of the current draft to make a
change that many of us wanted, to take this sort of approach to the
organization of that volume. 

This is beginning to take the shape of answers to some of our long-running

Yes, the charter that says our product is guidelines is broken.  Deferring
techniques to an afterthought document is not our strongest play.  Our market
opportunity is for techniques.  We can't steer the work toward guidelines and
then do an about face and say "W3C just does technology, not policy."  We need
to pitch our work so that even dummies can see we are not trying to tell them
what to do.  What we have to offer is how to do something that they can decide
to do or not to do.  We offer them what we know about who they leave out if
they don't do it, and how these techniques are beneficial across the board. 
But the mood of the utterance is 'here's  how."

Second, the relationship between accessibility and usability.  The answer is
that we use accessibility to detect problems, and we use usability to optimize
solutions.  The techniques that we offer are honed for broad-spectrum
effectiveness, not for mere problem avoidance.  The optimization techniques
as important to our customers as are the failure avoidance techniques.  So
let's give them equal time in our work.

This is what we need to carry to the Device Independence community. 
the flexibility of the morphs you archive and serve minimizes the count of the
morphs you have to archive and serve.  Use diversity and flexibility together,
it works better that way.

Received on Friday, 7 September 2001 18:12:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:38 UTC