Re: Accessibility-supported Technology

Hi,

At 00:25 16/09/2008, Li, Alex wrote:
>(...)
>In short, the degree of accessibility support for any given piece of 
>content depends on three variables: rely-upon-technologies, content 
>complexity, and techniques.
>(...)
>
>So, let's break down conformance responsibilities
>For technology owners and/or AT vendors
>  * Publish information about how to create accessible content and 
> the degree of support. To a degree, this is being done via IT or AT 
> documentation and VPATs.
>  * If no information is available from technology owner or AT 
> vendor, then it must be assumed by author and users that the 
> technology has no AT support and cannot be used as a rely-upon 
> technology in WCAG conforming content.


The first requirement for an accessibility-supported technology is:
<quote>
The Web content technology must be supported by users' assistive 
technology (AT). This means that the technology has been tested for 
interoperability with users' assistive technology *in the human 
language(s) of the content*
</quote>
<http://www.w3.org/TR/WCAG20/#accessibility-supporteddef>

This means that the human language of the content needs to be taken 
into account, so the set of accessibility-supported technologies for 
English may (and probably will) be different from the sets for Dutch, 
Chinese, Arabic, Russian or Maltese (consider support for speech 
synthesis, for example).
Is it feasible for an AT vendor or a technology owner to document 
accessibility support for more than just the 5 or 10 most popular 
languages on the Web? (For reference: Wikipedia is available in 158 
languages if you ignore those with less than 1000 pages.)
Are current AT documentation and VPATs sufficient or sufficiently easy to find?


>  * Programmatically exposing content info is not adequate in and of 
> itself because ATs or user agents don't always access such info or 
> do so adequately.
>For the authors
>  * Cannot claim conformance on technologies with no supporting 
> evidence of AT support.
>  * Specify all rely-upon technologies for the conformance claim.
>  * Reference accessibility documentation of rely-upon technologies.
>WCAG WG
>
>I think the idea of "only accessibility supported technologies are 
>relied upon to satisfy the success criteria" must be changed. Our 
>language says that there is such a thing as accessibility supported 
>technology and it must be used for conformance. The correct 
>reflection should be something like "only used content technologies 
>in a way as to allow AT to functionally meet the corresponding 
>success criteria." This addresses the situations in which the 
>technologies with no support at all and covers the rest of the 
>technology stacks in which the author needs the know-how to make 
>content conform.  So, instead of accessibility supported technology, 
>we have accessibility supported implementation.
>
>A recurring sticking point in which only one AT or some unpopular 
>ATs supports a given technology is still an issue. However, in no 
>way does WCAG specifies what degree of AT support is adequate for 
>content to claim conformance. That has always been a judgment call 
>by the author based on understanding of audience population. If we 
>require the author to reference the AT compatibility of rely-upon 
>technologies, at least we stand a better chance that the author will 
>make an appropriate and informed decision about what technologies to 
>use and how to use them.
>
>(...)
>All input are considered constructive.
>
>All best,
>Alex Li
>Manager, Accessibility Standards and Policies
>SAP Labs, Inc.
>3410 Hillview Ave
>Palo Alto, CA 94304



-- 
Christophe Strobbe
K.U.Leuven - Dept. of Electrical Engineering - SCD
Research Group on Document Architectures
Kasteelpark Arenberg 10 bus 2442
B-3001 Leuven-Heverlee
BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/
---
Please don't invite me to LinkedIn, Facebook, Quechup or other 
"social networks". You may have agreed to their "privacy policy", but 
I haven't.


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Received on Wednesday, 17 September 2008 17:36:10 UTC