Review and wording.

I reviewed the SC to see what wording might be needed to make them work with
our new plan.

My observations

1 - there are some that we need to work on for other reasons (no surprise)
2 - there are some that I think we should look at making advisory (later
topic)
3- not many need extra wording and it is usually just a phrase like "in a
standard and supported manner". to make the guidelines sufficiently defined
to
a) get 8 or 9 of 10 people to agree on outcome
b) prohibit things from qualifying (conforming) that should not (e.g.
alternate text is provided in the root directory in a file called
'aternate.html' with references to the explicit references to which images
on the site they refer to)

the items I see needing to add this to would be 
1.1 L1 SC5  
1.2 L1 SC 1,2, &3   L3 SC 2
1.3 L1 SC 3   (add "standard, supported" in front of markup)
2.2 L2 SC 1&2  (add "standard, supported" in front of method)
2.4 L2 SC 3


We may also want to do something with the following but I'm not sure what.
2.4 L3 SC 2 & 4
2.5 L2 SC 1 & 2


We do need to fix some other ones up though for other reasons.  But we are
still on track.


We need to define the terms Standard and supported. 

Definitions  (these are VERY ROUGH - just to get a discussion going)

Standard manner -  If a technology specifies that something be done in a
particular way (e.g. ALT for  IMGAGE in HTML) then that would be the
'standard' way to do it.  If there is no specification, then the way that is
generally used in the field is the 'standard' way.  In the case of 'general
use' evidence of general use can be found at W3C (e.g techniques document)
although multiple other common sources for this information can also be used
as evidence of 'general use'. 

Supported -  compatible with assistive technology or other user agents that
are readily available and affordable.  If the technique used requires a
special tool that in fact does not exist, then use of the technique does not
make the material accessible to anyone with a disability.  Hence a tool must
be available.  Provision of measures, even standard measures, that are not
supported by any technology does not, in itself, make something accessible
(though it may be good to do for future accessibility considerations).  
If the technique used requires purchase of special tool that is not
affordable, then again use of the technique does not make the material
accessible to anyone with a disability who cannot afford it.  Releasing
content that requires all users with disabilities (or a type of disability)
to buy a proprietary and expensive software package or plug-in in order to
access it would not satisfy this condition. (Free readers are provided to
non-disabled users for exactly this reason.)    However, requiring that all
AT be free is not acceptable either.  So we will need to have a long debate
and a lot of hand wringing before we can figure out what is OK.  And
international availability will also be an issue - though rules could be
applied according to the base language on the page perhaps (???).  In the
end, like the people who made the 1 in 12 slope requirements for wheelchair
ramps,  we will may have to pick some threshold which is reasonable but does
not address the needs of all users (there are many who cannot get up a 1 in
12 slope ramp).     We could try to ignore affordability - but I think we
are building into the guidelines all over already - and our baseline
discussion will bring this up too.    So this one will need thinking - but
not ignoring. 

Programmatically determined   - (include 'standard and supported' in its
definition.)

Programmatically located- (include 'standard and supported' in its
definition.)


Have a good meeting 



Gregg

------------------------

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/> FAX 608/262-8848  
For a list of our listserves http://trace.wisc.edu:8080/mailman/listinfo/

Received on Monday, 28 February 2005 19:34:51 UTC