[w3c-wai-gl] <none>

In our teleconference call Thursday, we had a discussion about how to
handle the differences in browsers and technologies they support.  Three
approaches were discussed for handling this problem.  Each of these is
presented below labeled A, B and C.  These are posted here to stimulate
discussion about the three approaches.

THE PROBLEM

Browsers vary in their ability to handle different technologies,
including style sheets, scripting languages, etc.  Often, browsers which
are accessible (such as LYNX) do not support technologies such as
scripting.

How do we handle writing guidelines so that pages that are written today
will be accessible with the browsers available today without creating
rules that perpetuate restrictions that will not be needed in the
future?

The three approaches for addressing this are:

A) Continue to use “until user agent” language to identify when there is
a guideline or checkpoint which is required today but which may go away
as technologies evolve.


B) Provide multiple specific techniques for addressing checkpoints.
Along with each technique, state those technologies which are required
for that technique.  Imply somehow that the technique should not be used
if the technologies are not supported by today’s access technologies and
provide a link to a location that would tell you which techniques (or
technologies) are accessible at any point in time.


C) Write the guidelines to work in the near future.  Bearing in mind
that the guidelines are renewed every year or two, separate those
technologies which are likely to be supported by AT in the short run
(one or two years) from those that are not likely to be supported for
two or more years.  Then, write the guidelines to assume that the
technologies that will soon be available are legal to assume when
writing your web pages.  Those that are not likely to be available soon
would not be mentioned as “potential future solutions,” since it isn’t
likely to be true for the life of the document.


The first two approaches have the disadvantage that if you just look at
the normative document, you can’t determine which techniques are viable
or not.  You have to link off to another separate non-normative document
to determine whether or not a particular technique is viable or
acceptable at any point in time.  They also both require that someone
keep updated analyses continually as to which technologies are or are
not supported in user agent and AT.  They have the advantage, however,
of being accurate if this is done.

The last approach has the advantage of being straightforward,
unambiguous and not requiring that people look up data in a second
document.  It also doesn’t require maintenance of a second document.  It
has the disadvantage, however, that at least initially it allows
techniques to be used on web pages that would not yet be supported by
assistive technologies.

In reviewing these options, it should be remembered that the “when user
agent” problem does not even exist for most of the guidelines.  The
three strategies above are suggested only for those few but important
items where we have this technology transition problem.

I don’t know which one I like best.

Your comments and thoughts?

Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
Professor - Human Factors
Dept of Ind. Engr. - U of Wis.
Director - Trace R & D Center
Gv@trace.wisc.edu <mailto: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
<mailto:listproc@trace.wisc.edu>

Received on Sunday, 23 September 2001 01:36:55 UTC