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

Re: Accessibility-supported Technology

From: Gregg Vanderheiden <gv@trace.wisc.edu>
Date: Fri, 19 Sep 2008 21:30:25 -0500
Cc: "WCAG" <w3c-wai-gl@w3.org>
Message-Id: <D0AE4B70-42D8-4FF0-B31F-FFD061548B31@trace.wisc.edu>
To: "Li, Alex" <alex.li@sap.com>


Looks like we have different readings of the guidelines.

We require AT support for TECHNOLOGIES (or uses of technology now)   
-   but we do not require support for languages.

In fact we early on decided that language access was not disability  
access. (or else you end up with the conclusion that you cannot  
conform to WCAG in 95 to 98% of the worlds languages).

If this isn't clear from the language in our docs then I agree we need  
to clean up the language.

If you (or anyone) has any suggestions, send them soonest so we can  
review them at next thursdays meeting where we wanted to address this  
if we can.


Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Ind and Biomed Engr
University of Wisconsin-Madison

On Sep 18, 2008, at 12:47 PM, Li, Alex wrote:

> Hi Christophe,
> You are right that the reality is that there is language dependencies
> for accessibility supported as we know it.  If there is no AT at all  
> for
> a language, say Vietnamese, can an author ever meet the bar of
> accessibility supported with a Vietnamese website?  Unless we change  
> our
> understanding of accessibility support, the answer has to be no.   
> Thus,
> no Vietnamese website can meet WCAG because no AT works with the
> language.  That's a real problem.
> Maybe there has to be room in conformance session for meeting WCAG,  
> but
> with no known AT support.
> As to documentation for supported languages, the logical source would
> still be the technology owners and AT vendors.  For example, I can
> easily tell you which language SAP supports.  Then there should be a
> cross reference from the AT end as to what JAWS, Dolphin, WindowEye,  
> or
> whatever would support.  There is obviously an OS dependency here too.
> All best,
> Alex
> -----Original Message-----
> From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
> Behalf Of Christophe Strobbe
> Sent: Wednesday, September 17, 2008 10:35 AM
> To: WCAG
> Subject: 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.
>> 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
> 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 Saturday, 20 September 2008 02:31:24 UTC

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