Accessibilit Supported Technolgoy

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 <mailto:alex.li@sap.com>  
http://www.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.