Re: Accessibility-supported Technology

Gregg,

I find it really difficult to argue that lack of AT support for a
language is not the author's responsibility, but lack of AT support
for a technology is.

And it seems a little odd that the requirements on authors when there
is no AT are so much less than when there is one AT.

It is starting to feel to me like we really do need a category for web
pages that are "AT ready", and that it covers both language and
technology support issues.

Loretta

On Sat, Sep 20, 2008 at 4:06 PM, Gregg Vanderheiden <gv@trace.wisc.edu> wrote:
> I agree with
>>
>> certain techniques may not be sufficient for
>> some languages if the AT supporting that language doesn't work with
>> the technique
>
> What I was concerned with was languages where there was no AT.    Most of
> the worlds technologies don't have AT support - and we don't want to
> preclude using WCAG for any of those.    Best to have them be proactive and
> set up so they will work with AT as it comes available in the language.
>
> I think we can fix that by looking carefully at our language and adjusting
> it so that it is clear that the above is covered but work in languages that
> is currently without AT is not discouraged.
>
> Gregg
> -----------------------
> Gregg Vanderheiden Ph.D.
> Director Trace R&D Center
> Professor Ind and Biomed Engr
> University of Wisconsin-Madison
>
>
>
>
>
>
> On Sep 20, 2008, at 10:10 AM, Loretta Guarino Reid wrote:
>
>>
>> Gregg,
>>
>> We decided that language access was not disability access, in the
>> sense that it is not  requirement to translate content into a
>> different language to provide access.
>>
>> But we did discuss that certain techniques may not be sufficient for
>> some languages if the AT supporting that language doesn't work with
>> the technique. So I agree with Christophe and Alex's interpretation.
>>
>> Loretta
>>
>> On Fri, Sep 19, 2008 at 7:30 PM, Gregg Vanderheiden <gv@trace.wisc.edu>
>> wrote:
>>>
>>> Hmmm
>>>
>>> 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.
>>>
>>> thanks
>>>
>>> Gregg
>>> -----------------------
>>> 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.
>>>>> 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 Saturday, 20 September 2008 23:14:26 UTC