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

RE: Reason Revisited

From: Gregg Vanderheiden <gv@trace.wisc.edu>
Date: Mon, 11 Jun 2001 00:49:37 -0500
To: <w3c-wai-gl@w3.org>
Message-ID: <003801c0f23a$4e8f1a00$b27ba8c0@750>
Good memo William.

Only thing I would highlight is that we can't have an "implied" provision if
we want to have these adopted as the rules or regulations around the world.
If there is a "within reason"  provision we need to so state somewhere....
And best if it is specific.    I guess one could say that we should put the
provision directly within the guidelines to the extent that that is within
reason.


Gregg



-- ------------------------------
Gregg C Vanderheiden Ph.D.
Professor - Human Factors
Depts of Ind. and Biomed. Engr. - U of Wis.
Director - Trace R & D Center
Gv@trace.wisc.edu, http://trace.wisc.edu/
FAX 608/262-8848
For a list of our listserves send "lists" to listproc@trace.wisc.edu


 -----Original Message-----
From: 	w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]  On
Behalf Of William Loughborough
Sent:	Sunday, June 10, 2001 9:27 AM
To:	w3c-wai-gl@w3.org
Cc:	Wendy Chisholm
Subject:	Reason Revisited

At 08:44 AM 6/10/01 -0400, Katie Haritos-Shea wrote:
>minutes updated

WL: How about [adding] the words "within reason" to the current guideline.

I think the full drill is "if/as/where/when appropriate/necessary" as well
as "within reason".

As we got more into moving from WCAG 1.0 to 2.0 I changed viewpoints (I
didn't participate materially in the details of 1.0) from thinking of this
as a major overhaul to realizing just how effective the original document
had been demonstrated to be. It has formed the basis for
policies/laws/regulations and actually spawned an entire industry of
services designed to enhance Web accessibility (and usability for that
matter).

It has been much maligned for opacity and for "leaving out" major segments
of PWD yet the changes proposed/made have been for the most part editorial.
Generalization/abstraction have been accompanied by slight changes in
emphasis but always an almost total mapping of the previous checkpoints
into the new document.

What we find ourselves wrangling over are almost always the devilish
details: the underlying principles are still rather solid.

The thread that is most recent in this process involves user control of
various timed events and the idea of what would be "reasonable" to expect
from the provider/content/user matrix. Put simply, we don't want to make it
impossible for someone who cannot "just click here" within an allotted few
seconds while at the same time we don't want to hogtie a huge enterprise
from making server activity efficient by requiring that they allow
unlimited unattended shopping carts ("deposits made after 5 PM will be
credited on the next business day", etc.).

We pretty much understand this problem and even have rough ideas about how
long certain instances should take, etc. On one hand we don't want to put
"seconds/hours" into a checkpoint yet we must protect someone who needs a
bit more time to send Morse code via a sip/puff straw to an interactive
form.

I proposed that this and a great many (all?) checkpoints be considered to
have a tacit "within reason" phrase for just about every term therein. E.g.
"Provide a text equivalent for all non-text content" might have as
a  "reasonable exception" making certain exceptions as is already done with
alt="", "Synchronize text equivalents with multimedia presentations" might
encounter discovery that there are instances where synchronization is
meaningless/unimportant, "Synchronize a description of the essential visual
information in multimedia presentations" clearly requires judgement as to
what is "essential", "Use markup or a data model to provide the logical
structure of content" makes no allowance for the possibility of there being
such a thing as "unstructured content", and that's just the first few
checkpoints.

We will never find *all* the examples that require intervention of reason
on the part of content providers and in order to maintain a "liftable"
document we must restrict the potentially endless array of
caveats/exceptions/examples we furnish.

As in the cited example, we can collect many of the ruminations into the
techniques/examples section so that the harassed designer has practical
guidance to accompany the ideals of the checkpoints. We must give a
"flavor" that delineates the approach  needed to make content accessible,
particularly for those who come clueless to our table. They want their
stuff to be widely available in the "increased market share" sense as well
as being required to conform to *something* - and as many detailed answers
as possible should accompany (but not bloat) the document.

Gregg proposed that I try to locate "bright lines" that might exemplify our
intent without burdening the checkpoints and I will keep trying, but I
think we must all take one step back, a deep breath, and not try to include
examples in the guidelines/checkpoints themselves but in their explanatory
accompaniments, including the "lead-in" paragraphs and "post-checkpoint"
summaries. To mix metaphors: our "Ten Commandments" will have an extensive
"Federalist Papers" backup.

In summary, the introduction is so much friendlier, the organization so
much "cleaner", and (at least the plan of) the techniques so much more
practical/specific that we can expect much better use to be made of 2.0 if
we keep on keeping on.

--
Love.
                 ACCESSIBILITY IS RIGHT - NOT PRIVILEGE
Received on Monday, 11 June 2001 01:51:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:10 GMT