Thread Subject: AT support in 508 and 255

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Gregg Vanderheiden
Date: Mon, Feb 25 2008 12:15 PM

I thought it would be helpful to pull together some thoughts in preparation
for next week.





Since summaries alone are not helpful without proposals, let me start with
the bottom line (the proposals) and then provide the rationale








PROPOSAL





Part 1 to address Assistive Technology language in the Functional
Performance Criteria




Remove the words "directly or through assistive technology" from all of the
FPC and put them as a lead in paragraph to all of the FPC such as the
following.



<proposed text>

The functional performance criteria are [INSERT THE PURPOSE OF THE FPC -
AFTER WE DECIDE THAT NEXT WEEK].



The FPC state what should be possible with the product, but do not specify
specifically how this would be accomplished. In some cases the access to
the functionality of the product may be direct, without any assistive
technologies. In other cases the access may be possible if a piece of
assistive technology is used in conjunction with the product (screen reader,
special keyboard, etc.). Either means for achieving access would satisfy
section 508. For section 255, access must be direct if that is readily
achievable. If not, then access via assistive technology must be provided
if it is readily achievable.

<end proposed text>










Part 2 (to address 3-F)


To address access in provisions 3-F, and ensure that 'text' is not
interpretable to mean 'images of text" that cannot be accessed by AT,
create a new definition of text (adapted from WCAG) to ensure that text can
be read by AT as words.



<proposed definition>

Text

sequence of characters that is
<http://www.w3.org/WAI/GL/WCAG20/#programmaticallydetermineddef>
programmatically determinable, where the sequence is expressing something in
<http://www.w3.org/WAI/GL/WCAG20/#human-langdef> human language

<end proposed definition>












Part 3 (to address provisions 3-G, 3-H, 3-N, 3-O, and 3-P)


Change definition of programmatically determinable to make it clearer that
programmatically determinable means that it can in fact be determined from
Assistive technologies. Current definition says this in a very roundabout
way. Either that or the definition doesn't actually require that information
be determinable by AT. Either way we should simplify this to say simply
that programmatically determinable means that AT can determine it. Otherwise
3-F (All Non-Text Objects), 3-G (Human Language), 3-H (Language of Parts),
3-N (link purpose), 3-O (information and relationships), and 3-P (User
Interface Components) will not be required to actually work with AT.



<CURRENT DEFINITION>

Programmatically Determinable

Can be determined by software from data provided in a user-agent-supported
manner such that various user agents including assistive technologies can
extract and present this information to users in different modalities.





<PROPOSED DEFINITION>

Programmatically Determinable

determinable by user agents, including assistive technologies, from the data
provided

NOTE: Purpose is to allow user agents including assistive technologies to
extract and present this information to users in different modalities.

NOTE: Programmatically determinable requires that the information be
determinable by existing assistive technologies.

<end proposed definition>












Part 4 (to address provisions 3-U and 3-V)


As written, this provision appears to be very clear about working with
Assistive technologies. However, several people have asserted that it does
not in fact mean that it would work with any existing assistive
technologies, just that it could theoretically work with assistive
technologies if an assistive technology were to be designed to work with the
product. To ensure that it is clear that the provision means that the
product must work with actual AT that a government employee (or member of
the public for public facing E&IT) can get we should add the following note
to provision 3-U



<proposed text>

Note: The term 'assistive technology' in this provision and provision 3-V
refers to assistive technology that exists and that is available to
government employees (or members of the public for public facing E&IT).

<end proposed text>
















Part 5 to address


1) the problems faced by companies


a. when products almost work with AT,


b. would work with AT if AT bugs were fixed,


c. or used to work with AT but stopped with a new version of AT.


2) need for a legitimate way to have APIs be sufficient. )





There is much push back to saying that products must work with actual AT
because of the fact that product manufactures cannot guarantee that their
products will work with all AT, or that it will work with any AT that has
bugs in it that companies cannot easily work around. (Also work arounds are
prone to instability and failure later on - so are usually not good
solutions to start with).



To address this we should not say that products do not need to work with
real AT. (That would mean that products don't have to really be operable
by people with disability in the government or public).



Instead we need to suggest some strategies that could be used by procurement
agencies and regulators to allow companies to do what they can - be rewarded
for going the extra mile with AT vendors - but not be left out to dry if AT
vendors are not willing or (more often the case) not able to fix the bugs
causing the problem with the product.



Also need to include a method for APIs to be acceptable when they are in
fact sufficient.



Suggest we add to the preamble.





<proposed text>

In these standards, some provisions require products to work with assistive
technologies. In order for products and assistive technologies to work
together it is (except for certain very well defined interconnections)
necessary for both sides to work together. Sometimes assistive technology
vendors do not have the capacity to work with every product vendor, even if
the product vendor provides incentives or covers some or all of the cost.
In these cases it may not be possible for a vendor to guarantee or even
achieve full compatibility with those assistive technologies. It is
recommended that procurement policies take this into account and make
provision for product purchases while still keeping in mind the fact that
products that will not work with assistive technologies in substantive ways
will not be useable in substantive ways by employees with disabilities or
members of the public.



As mentioned above, there are some very well defined interconnections where
compatibility with a test tool has been proven to be sufficient to guarantee
that products will work with assistive technologies. Where APIs or other
standard interconnections exist that have been proven to be sufficient to
guarantee compatibility with existing assistive technologies, then passing
the test should be admissible as compatibility with those assistive
technologies that the tool is certified for. The Assistive Technology
Industry Association (ATIA) would be a good source to identify any tools
that are developed for this purpose and proven to be effective.

<end proposed text>
















Part 6 (to address the question of "which AT" products must work with)




Although it is important that products work with be AT that employees (or
members of the public) would reasonably be expected to have or to be able
get. (and, for members of the public, afford), I think that we should just
be silent on this topic. There is a lot involved there - much of which is
beyond these guidelines and beyond the Access Board, to address.



Suggestion:



<proposed >

That we just talk about products needing to work with AT but that we do not
specify which AT.

<end proposal>


















Rationale / Notes




These edits are required to remove ambiguity about whether a product is
accessible or meets 508 if it does not work with actual existing assistive
technologies.



The question has been raised as to whether this is necessary. Should a
product be required to (be directly accessible or) work with real AT? Or
should it be good enough to pass 508 if the product has an API and COULD
work with an assistive technology if one were designed to work with the
product (even if there isn't any assistive technology that actually is yet).




I believe that the answer is No - an API is not good enough. Products
must be directly accessible or be accessible via existing assistive
technologies. This may be through an API or it may not. The API is a good
strategy but neither necessary nor sufficient if the product does not work
with real, existing assistive technology.



a) the LAW. 508 and 255 are both about making products accessible to
people with disabilities. If a product works directly (without AT) that
fulfils the intent of the Law. If it doesn't, but works with AT (that the
person can get) then the person can still do their job and the intent of the
law is met again. If there is an API, but it won't work with any AT the
person can get - then the person cannot do their job (or be hired - or
promoted into the job) and the purpose of the law(s) is not met.



b) Not less than last time. In the past, companies have been testing with
AT, and agencies have been asking which AT the product worked with. One
company went through the trouble of creating their own screen reader when
the existing one went off the market. No documents say that an API with
out AT is sufficient. To create a document now (the TEITAC report) that
states (directly or indirectly) that an API that does not work with real AT
should be considered to meet the implementation requirements of the laws
(508 or 255) would be a significant step backward.



c) 255 language. 255 specifically says that it must be "compatible with
existing peripheral devices or specialized customer premises equipment
commonly used by individuals with disabilities to achieve access, if readily
achievable" (if it is not readily achievable to make it directly accessible
).








RE API/interconnection sufficiency:





There was a suggestion to ATIA to publish list of ATIA tested and certified
tools (and develop them if and as possible) that can be used to test for
compatibility with whole classes of AT.

This was discussed with an ATIA rep and it was felt to possibly be a way to
work toward an API approach over time if and where it can be established
that passing a test would ensure that products would work with existing AT
then passing the tool/test would be sufficient.

Places where this might be true today

* USB keyboard replacement AT

* USB mouse and pointer replacement AT

* Software that generates keystrokes that appear in the OS as if
they came from the physical keyboard and that places very predictable (and
simulate-able) demands on the OS, displays, and peripherals.

Place where it is not true today

* Screen readers

* Screen magnifiers

* Alternate inputs that directly interact with applications

* AT that requires application scripting


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University