Thread Subject: Re: 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: Brad Hodges
Date: Mon, Mar 03 2008 6:50 AM

Colleagues:

I read with interest Peter's well crafted and concise commentary. As you
may recall, at our last face to face meeting I articulated my concern
that the responsibilities of AT may not be represented in the TEITAC
report or proposed regulations.

I wish to reiterate my thinking on this important and obviously
controversial issue. AT has a role to play in the many relationships of
IT and AT which take place every day. AT while unique in many important
ways is not totally divorced from the reality of many other specialized
technologies which interact with and support the general universe of
technology.

With respect to the TEITAC report, it is reasonable to require AT to use
any API information provided by an application if appropriate to provide
accessibility or if the AT has no other mechanism to provide
accessibility to the application. This allows AT to use any method which
is thought to be better than the API, and at the same time ends
situations in which API information is ignored, resulting in
inaccessible applications which could be accessible.

At the same time, I believe it is equally important to isolate AT from
requirements and responsibilities which are beyond the technical and
commercial scope of the industry.

I look forward to a productive conversation on this important topic and
remain hopeful that consensus can be reached.

Brad Hodges

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
Korn
Sent: Saturday, March 01, 2008 2:45 AM
To: TEITAC Committee
Subject: Re: [teitac-committee] AT support in 508 and 255


Hi Randy, Gregg, all,

I think this is one of the better discussions we've had on this topic,
as we are managing to find at least some language we are all largely in
agreement on, and perhaps are narrowing some of the differences [whether
enough to reach consensus, I'm not sure...]

More comments in-line, with trimming to save on the size of the e-mail.
First level quote is Randy, 2nd level me, third (most-quoted) is Gregg.




<SNIP>


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>


I'm happy with your proposed new definition and with
your first new note. I disagree with your second note - and that goes
to the heart of the 3-New Assistive Technologies provision. I believe
something should be "programmatically determinable" [full stop] whether
or not AT is in the picture. If and where we want to mean
"programmatically determinable by existing AT", then we should spell
that out in those places. I think this is particularly important in
light of common engineering understanding of this term (and will cause
significant confusion if we define it to mean more).




ATIA> The point of being programmatically determinable is so AT
can use it. Removing AT from the picture sort of defeats the purpose.


Randy - would you say that HTML markup is programmatically determinable
so that AT can use it? Or that it is programmatically determinable, and
some AT have chosen to parse it for their own purposes (while in other
cases it is parsed for non-AT uses)? Likewise Win32 API calls that AT
uses today to obtain information about items in menus (vs. using MSAA to
do this) - they weren't put into place for AT, but some AT found them
useful and happen to use them.

Certainly in the context of accessibility regulation, when we talk about
programmatically determinable, we are looking at the use this
information would be put to by an AT; but that information may have more
general uses - not simply for AT. Which is why I would prefer to have
us spell out "programmatically determinable for AT" where we use the
language, rather than putting the "for AT" part only in a definition,
where it may be easily missed by folks reading the text (I would argue
much more easily missed than a "<something> AT" might be at the start of
the FPC section vs. being repeated in each FPC!)








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>


I think we need to look at this in the context of 3-New
Assistive Technologies. Coming out of the AT-IT task-group, the EWG
pulled all of the provisions relating to AT-IT interoperability into
their own temporary section for ease of review (whether or not they have
been consensed). Please see
http://teitac.org/wiki/EWG:Draft_Jan_7#Collected_Material_for_Assistive_
Technology_and_Interoperability Perhaps we will review all of these
next week Tuesday...


AITA> The proposed text of 3-New Assistive Technologies is a
problem for us for two reasons. First of all, there isn't millions of
dollars in potential Federal purchases at stake for AT companies. So
even if we say "AT must do this" in 508, many of the small AT companies
may still choose not to (due to limited development budgets, the need to
support legacy users, only supporting certain platforms where there is
market demand, and so on). So it won't accomplish the desired purpose.
The second concern is this will leave a big hole in 508 that would allow
IT to say "we did our part, so it must be AT's fault", and then be off
the hook. AT doesn't need to be told that it must interoperate with IT
- that is the essence of what AT is. Mandating it in 508 will only
provide an "out" for IT companies that may be looking for one. If API's
are available, most AT will gladly use them. But simply supporting them
in an IT product isn't enough - real-life collaboration and testing with
AT must still take place.


I really don't see this as an "out for IT"; I don't think any of the IT
colleagues in TEITAC see it that way either. I see it as the least
restrictive and least onerous of the triumvirate of 3-U, 3-V, and 3-New
AT. There are three components to most accessible installations on a
desktop, and the procurement must take care to make sure that all three
work together. As you noted in the your message, this is the
responsibility of the procuring agency. What should they do to ensure
that the three things they are purchasing - typically at different times
- work together? What direction do we give them? We've given them
clear direction in the case of the platform and apps...

I'm also a bit confused by two things you have said above. First is
that "many of the small AT companies may still choose not to" utilize an
accessibility API if provided, and second is "If API's are available,
most AT will gladly use them." These seem to be somewhat in conflict; I
guess you are saying essentially that more than 50% of AT will use an
API (the "most"), but something greater than 10% or 20% won't (the
"many"). Do I have that right?


Looking at the history of AT-based accessibility... In the 1960s
through most of the 1990s, AT essentially did all the work, with perhaps
a bit of help here and there from IT vendors toward the middle & end of
the 1990s - accelerating around 1996/1997 with the introduction of MSAA
and the Java Accessibility API, and in the early 2000s with the UNIX
accessibility framework and then the Apple accessibility framework, and
finally UI Automation & IAccessible2. With the passage of the update to
508 and the publishing 508 regulations, AT was still doing almost all of
the work (especially on the Windows platform), but one interpretation of
the FPCs had it that IT was solely responsible for making the AT side of
things work, and certainly from a procurement point of view, it was only
ever IT sales at risk. And at the same time, the trend of IT
interoperability assistance, work, etc. with AT has continued to
accelerate.

Now with the TEITAC draft, we have a very detailed and explicit set of
things IT must do to work with AT (which I think all agree is great).
Yet I sense a fear in you that unless we at least retain language that
under one interpretation means that IT is solely responsible for making
the AT side of things work and under which from a procurement point,
IT's work with and commitment toward AT interoperability will somehow
dry up and wither away. Is that correct? 'cause I just don't see that
happening, and certainly not as a result of having a set of
responsibilities spelled out.

I wonder, would a separate pledge - outside from procurement regulation
- from a broad collection of industry stating that "we pledge to work
with AT vendors, to collaborate on interoperability, have and hold, 'til
death do us part" (or something like that) help ease your worries?



Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

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