Re: Accessibilit Supported Technolgoy

Hi Alex

    Your conclusion is in synch with what we found.   In working on  
documenting accessibility support we found that what we really are  
talking about is  "uses" of technology (or features of technology)    
(  e.g  USE of alt on IMG    or  USE of alt on AREA).

    So we need to say that
"When relying on AT (and access features in browsers) to make content  
meet a success criterion,
  authors must use technologies and features of technologies in a way  
that is supported by AT (and access features in browsers)".

We can find ways to say that in plainer language but that is the gist  
- and I think it agrees with your conclusion if I read it correctly

Let me take a crack at edits to the docs to reflect this -- that also  
incorporate our previous discussions in the group on this which also  
came to roughly the same conclusion.


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






On Sep 15, 2008, at 5:25 PM, Li, Alex wrote:

> Hi WCAG WG,
> The recent discussion regarding the accessibility support database  
> has inspired me to give the concept deeper review. I hope it is not  
> too late to revise the concept.  Below is my effort to improve our  
> deliverable.  We ought to resolve this before we wrap up the face-to- 
> face meeting.  Sorry about the length of this write up.  I think it  
> is important to resolve this issue.
>
> Assumptions and backgrounds
>
> We should establish a common understanding that no technology today  
> or likely in the near future can be 100% accessibility supported  
> under all conditions. It can be attributed to compatibility between  
> technology, content, OS, AT, user agents, etc. Even the most common  
> denominator, html, cannot be fully supported in all cases. So for  
> the sake of this discussion, let’s establish that 100% is not  
> feasible.
> The opposite extreme is 0%. It is possible that a technology,  
> especially ones that are brand new, to be able to meet WCAG 2.0  
> success criteria in theory but not be compatible with any AT. This  
> is a special condition in which our final output should be able to  
> handle. But I want to note that technologies in this category are  
> exceptional cases.
>
> In between the extremes of 0% and 100% accessibility supported is  
> where most technologies are. Making content conform is about how to  
> use these technologies. Technology selection affects the work it  
> takes to achieve conformance, but the selection itself does not  
> determine whether the content conforms. There are four main  
> strategies to achieve accessibility any given technology. I list  
> them to the order of easiness:
>
> · Follow the technology guideline and/or use an appropriate  
> authoring tools
> · Avoidance—for example, avoid using tables in the conformance  
> content if the technology has issues with tables
> · Alternative—use alternative version to get around technological  
> restrictions
> · “Hacks”—use technology in a way that deviates from specifications  
> or norm to get around restrictions or invent a solution
>
> This leads to the concept of content complexity. Content complexity  
> can range from the simple “Hello World” scenario to using every  
> bells and whistles possible. Similar to the above discussion on  
> technology, most real world scenarios are somewhere between the two  
> extremes. Less complex content tends to use the first two  
> strategies. As the complexity of the content increases, author may  
> have to ratchet up to use alternative or “hacks”. There is a  
> converse relationship on accessibility support of the technology.  
> The less AT support a technology has, the more the author has to  
> hack or use alternative version.
>
> In short, the degree of accessibility support for any given piece of  
> content depends on three variables: rely-upon-technologies, content  
> complexity, and techniques.
>
> One last piece of background information that may affect our  
> decision is that there are relatively few technology owners compared  
> to authors. Most of the technologies are “owned” by a few companies  
> or standard organizations. That is also the case for AT products.  
> There are far more authors than AT vendors.
> The Problem
>
> It is impossible to determine if any given technology is  
> “accessibility supported” because no technology is 100% accessible  
> to all ATs.  If we draw the line at 100% AT accessibility supported,  
> no technology would pass.  If we draw the line at 0%, most  
> technologies would pass.  The term would have very little meaning.   
> Drawing the line somewhere in between 0% and 100% is not feasible  
> because the degree of accessibility depends not only on technology  
> selection.  For some type of content, it could be possible to meet  
> WCAG with a given technology.  While it may be impossible to conform  
> with different content with the same technology.  Also, a  
> sophisticated author could meet WCAG with a given technology.  While  
> a different author may not be able to meet WCAG using the same  
> technology to build the same content.  Thus, drawing a line in the  
> sand to determine which technology is and is not “accessibility  
> supported” is inappropriate unless it is okay for one site to claim  
> a given technology is accessibility supported and another to claim  
> otherwise.  This approach would also make the term “accessibility  
> supported technology” meaningless.
>
> Analysis
>
> We have established that, except in those cases in which technology  
> with zero accessibility support is relied upon, content  
> accessibility is the result of author making good use of  
> technologies for the purpose of the content.
>
> Depending on the technology and content complexity, the author may  
> employ any or all four strategies stated above. In the case of  
> technology with zero AT accessibility support, nobody should rely on  
> it to conform to WCAG. It is the author’s responsibility to check  
> how well a technology is supported by AT during the time of content  
> development and conformance claim. This must be done anyway because  
> the author must investigate how to use the technology to provide  
> accessibility. Authors who do not investigate on this are very  
> unlikely to produce WCAG conformance content. Certainly, any  
> conformance claim without such investigation and implementation  
> would not result in an informed or reliable claim of conformance.
>
> On the other hand, AT/IT compatibility changes constantly. It is  
> inefficient for authors, which numbers far more than technology  
> owners and AT vendors, to change conformance claim constantly. It is  
> logical that technology owners and/or AT vendors to be the source of  
> information about how a technology is supported. I know it is  
> inconvenient for the users, but I would not trust most authors to  
> keep up with the latest AT/IT compatibility updates.
>
> 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.
> 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.
>
> I do not profess that this is a magic bullet solution.  It was  
> pointed out to me that it would not be easy to document whether and  
> how html allows an author to conform to accessibility supported  
> implementation.  Documentation is not abundant in terms of user  
> agent and AT support for html.  But I think that is where we need  
> better documentation—from AT vendor or technology owners.  Perhaps  
> that is where the database can help.
>
> In terms of WCAG content, I think what we need to do is to change  
> the language around “accessibility supported technology” to  
> something like “accessibility supported implementation”.  I believe  
> the concept of “accessibility supported” is still generally sound.   
> We may have to ask the implementation site owners to add some  
> reference on top of existing conformance statement to make the claim  
> valid.
>
> I want to thank Andrew, Andi, and Sofia for their input on this.   
> This write up by no means represents their point-of-view.  But their  
> contribution to my draft has greatly improve the quality of the  
> material.  Any problem you see with my argument reflects only my  
> inability to reflect their wisdom.
>
> All input are considered constructive.
>
> All best,
> Alex Li
> Manager, Accessibility Standards and Policies
> SAP Labs, Inc.
> 3410 Hillview Ave
> Palo Alto, CA 94304
> T (650) 687-4770
> F (610) 492-2961
> M (202) 492-4592
> mailto: alex.li@sap.com
> http://www.sap.com
> THE BEST-RUN BUSINESSES RUN SAP
> This e-mail is confidential and may contain privileged information.  
> If you are not the addressee it may be unlawful for you to read,  
> copy, distribute, disclose or otherwise use the information in this  
> e-mail. If you are not the intended recipient please notify us  
> immediately.