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

FW: Questions and proposed approaches for Baseline Specifics

From: Gregg Vanderheiden <gv@trace.wisc.edu>
Date: Wed, 6 Sep 2006 14:57:33 -0500
To: <w3c-wai-gl@w3.org>
Message-ID: <000601c6d1ee$b2e8a310$8c17a8c0@NC6000BAK>
In looking at the baseline issue, three questions have arisen that aren't
covered well in current documentation on it. 


1) What do we mean by a technology.  Do we mean a particular specification
or a general type?

2) What if there is an extension of a technology that someone developed.  Is
it included?  What about modules that extend a technology?  If they are
supported by User agents including AT - shouldn't they be part of baseline?
Are they?

3) What if there are features of a technology that are NOT supported by AT.
And if using them would make a page (or that part of the page) inaccessible?
Can they be used WITHOUT providing an accessible alternative? 



The following is a pass at answering these questions.   Posted here for



1.      We use WHOLE technologies in the Baseline (Like HTML or CSS).

2.      We probably DO need to specify which versions (e.g. HTML  3.2 thru
4.01 )

3.      We also allow extensions (e.g. Embed) and modules where they are
supported by AT and should be in a baseline. 

4.      If there is an element within a technology specification that is not
supported by AT we can:

a.      Not include it as a sufficient technique (e.g. not include 'object'
in our list of sufficient techniques)

i.      This does not say an author can't use it.  

ii.      It just says that the author must defend the fact that it is usable
and supported by user agents INCLUDING AT. 

b.      If it is really fatal - and use of it would prevent an SC from
working - we can list it as a failure.

i.      e.g. If eBook files have a setting that prevents it from being read
by AT then it would fail 1.1.1 and you could list the use of that setting as
a failure under 1.1.1. 

(NOTE: only things that clearly fail an SC can be listed as a failure.
Failures do not tune or modify SC.  They only make it clearer to people less
familiar with the field when a failure has already occurred for an SC). 


This solves all the problems created by technologies that have particular
features that either a) are not supported by AT or b) interfere with AT.
It also allows addition of extensions to technologies where those extensions
are supported by User Agents INCLUDING AT. 


It DOES assume that there is a tie between creating the Baselines and
creating failures.  If a technology with a bad feature (such as AT lockout)
is put into the Baseline - then the use of the feature should be listed as a
failure at the same time.  Presumably, before a technology is put into a
Baseline, there is a set of 'sufficient techniques and failures' available
for it. 


This is all based on the assumption that only people who know AT will be
putting together Baselines.  All others should use Baselines created by
those that do know AT because the Baseline concept is designed to
recalibrate the guidelines to AT over time.  Without AT knowledge, it isn't
possible to create good Baselines. 


If an author chooses a reputable and up to date Baseline  (e.g.   WAI 2007
Baseline for General Internet Use)  then they should not need to understand
AT support (good if they do but not required).  They should be able to use
that baseline and the sufficient techniques and failures documented by WAI
and be able to assume their content is accessible.    If they use OTHER
techniques than those documented as sufficient - then they would need to
understand what they are doing and be ready to defend it.   (This is
standard  "equivalent facilitation" approach). 






Gregg C Vanderheiden Ph.D. 
Professor - Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 
< <http://trace.wisc.edu/> http://trace.wisc.edu/> FAX 608/262-8848  

The Player for my DSS sound file is at  <http://tinyurl.com/dho6b>



Received on Wednesday, 6 September 2006 19:58:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:34:01 UTC