Thread Subject: Re: APIs

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: Wed, Mar 21 2007 10:10 AM

Some observations from the list and discussions and past work that has been
done on this.



1) API's can decrease (often greatly) the amount of work needed to create
access by AT vendors

2) They can also reduce the time needed by IT vendors in supporting multiple
different AT vendors.

3) From working with many companies it has become clear that APIs don't
allow products to work together without testing and tuning. This is not just
an accessibility issue. It is true of mainstream APIs as well. Companies
have Plug-fests all the time and IT companies have large test labs and make
their engineers available to other companies to help make their products
work together. So technologies that implement APIs must be tested. .

4) An API by itself does not make a product more accessible if there is
nothing that works with it. The API doesn't make a product usable by
people with disabilities. It just facilitates the creation of AT that can
make products usable by people with disabilities.

5) AT can provide access without an API. Some AT works without APIs today.
Though for some types of IT/AT would be very difficult without an API.



This seems to lead to

a) APIs can be extremely valuable to both IT and AT companies.

b) APIs are to be encouraged.

c) APIs are not sufficient. Nor are they always required.

d) The stated objective of 508 is to have E&IT accessible and usable by
people with disabilities. To do this either direct access or compatibility
with some real AT is required.

e) Per #3 and #4 above, the compatibility with AT described in item (d)
cannot be achieved without interaction with AT vendors. (an API alone won't
suffice)



Possible implications for our work?

Our provisions therefore need to say what direct access or AT needs to
provide. APIs and API requirements can help in the process but are only
that: part of the process. An API by itself without AT that works with it
to provide the needed functions would not meet 508. And for some simple
E&IT an API may not be necessary.

For robustness we could include the specifications that IT should meet with
an API - but unless users have AT that will reliably work with the API -
there is no access by users.

TO DO LIST

TD1) create specs for what needs to be available (either directly or via AT)
so that we have more detail than just the functional performance (e.g.
"usable by people without xxx". )

TD2) Decide if we want to include specifications for APIs in addition to
requiring that there be AT that meets the specs in TD1). If so develop
them. (APIs for Software only? Equiv for hardware? )

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

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto:teitac-general-
> = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
> Sent: Tuesday, March 13, 2007 5:02 PM
> To: TEITAC General Interface Accessibility Subcommittee
> Subject: Re: [teitac-general] What is good enough to qualify for
> compatibility with AT?
>
> Hi Randy,
>
> My responses are in-line, below.
> > I hate to sound like a broken record (or stretched cassette tape, or
> > scratched CD, or defective MP3 player, or faulty audio storage device
> that
> > hasn't been invented yet...), BUT... I disagree.
> >
> > The suggestion is to remove IT's requirement to work with AT and replace
> it
> > instead with a small set of API's that each side can design to.
> Correct?
> > But to what end?
> >
>
> No, I don't believe that is what is being discussed.
>
> Right now we have a handful of technical requirements which supposedly
> help AT work with IT (but as has been discussed at length in the Web &
> Software group, are in many cases no longer appropriate if they ever
> were); and we have the broad and fairly vague repeated requirement in
> 1194.31 to either have a "mode of operation" that doesn't require a
> variety of user capabilities, "or support for assistive technology used
> by" that user community.
>
> It doesn't say explicitly "you must work with AT vendors", and it
> certainly doesn't say explicitly where precisely the responsibility lies
> for AT-IT interoperability, beyond the functional criteria items noted
> above.
>
> This is where this thread started, with David Baquis asking for this
> question to be addressed (see his message, which is the bottom-most
> quoted message, at the bottom of this e-mail).
>
> > If it is not economically feasible for an AT vendor to support a certain
> > product or platform without the API's, it will still be so WITH the
> API's.
> > This approach may simply give the IT vendor the ability to say "Hey,
> we've
> > done our part" and proceed to sell their products to the Federal
> Government,
> > which still don't work with existing AT.
> >
>
> At TEITAC #3 you gave a compelling demo of automatic switch scanning of
> a GUI on the Macintosh, using the Apple accessibility API. You showed
> it working with some of the built-in applications. You didn't show it
> (for example) with MS-Office on Macintosh - which I note does not
> currently implement the Apple accessibility API. This seems to
> contradict your statement above. It was/is economically feasible for
> Madentec to support this very compelling switch access to applications
> that support the Apple API. Is it similarly economically feasible for
> you to do so with applications that don't support the API?
>
> > On the other side, if you demand that AT companies spend development
> dollars
> > on products which they won't sell any of, one of two things will happen:
> > they will either ignore the requirement, or they will go out of
> business.
> > Neither scenario achieves the desired objective of providing accessible
> IT
> > to Federal employees with disabilities.
> >
>
> I agree that we should not demand/require this. No argument here
> Randy. I don't believe anyone is suggesting this anymore - we hashed
> this out at some length a couple of months ago.
>
> > If an IT company manufactures a product for which no AT exists, they
> have
> > three choices:
> > 1. Build accessibility directly into the IT product
> > 2. Built their own AT
> > 3. Work with AT companies (which may mean providing resources)
> to
> > adapt their solution to be compatible with the IT product.
> >
>
> We need to distinguish software application from platform. They are two
> distinct situations. Today we have existing platforms with AT on them,
> but with insufficient support for AT-IT interoperability, making it much
> harder than it needs to be to get AT and IT working well together. We
> also have existing platforms with no AT on them. Oh, and we have a
> couple of platforms which pretty rich support for AT-IT interoperability
> (though as was pointed out in TEITAC #3, "pretty rich" is not the same
> as "perfect, with no need for cooperation, debugging, and testing").
>
> Looking then at these three distinct cases, I suggest that in fact there
> are a lot more choices than just the 3 you outline:
>
> A. On a platform with no existing AT, no support for AT.
> Platform choices are:
> 1. Make the platform self-accessible (for blind, low vision, physical,
> auditory, cognitive)
> 2. Build AT yourself without creating an architecture/API to support AT
> 3. Build AT yourself, on top of an architecture/API to support AT
> 4. Pay AT companies to support your platform (perhaps with or perhaps
> without an architecture/API to support AT)
> 5. Be an important enough platform (sufficient popularity/sales) to
> draw an AT industry to you that does the reverse engineering needed to
> make your platform accessible (shifting you to scenario B below)
> 6. Claim an exemption of some sort
> Application choices are:
> 1. Make the application self-accessible
> 2. Claim an exemption of some sort
>
> B. On a platform with existing AT, little/no support for AT.
> Platform choices are:
> 1. Work to not break existing AT, help them continue to reverse
> engineer your platform, as your platform evolves
> 2. Build AT yourself (and potentially harm the existing 3rd party AT
> ecosystem)
> 3. Build an architecture/API to support AT, allowing you over time to
> shift resources away from #1
> Application choices are:
> 1. Make the application self-accessible
> 2. Be an important enough application (sufficient popularity/sales) to
> draw AT to you to reverse engineer and otherwise make you accessible
> 3. Pay AT to support you
> 4. Invent an accessibility framework/API that makes it easier for AT
> to support you, and then some combination of #2 and #3 above to get AT
> to support you
> 5. Claim an exemption of some sort
>
> C. On a platform with rich support for AT
> Platform choices are:
> 1. Build AT yourself
> 2. Be important enough (sufficient popularity/sales) to draw AT to
> your platform
> 3. Pay AT to support you
> Application choices are:
> 1. Make the application self-accessible
> 2. Support existing AT by implementing the accessibility framework/APIs
> 3. Claim an exemption of some sort
>
>
> At Sun, when faced with these choices, we made the following decisions.
> On Windows our applications defined their own accessibility API, and we
> worked with AT vendors to support them (Java applications and
> StarOffice/OpenOffice.org). While both of these are quite
> important/popular (there are many tens of millions of copies of
> OpenOffice.org running on Windows, and virtually every large
> company/organization is using Java somewhere), they are still
> insufficiently so to attract a large amount of AT support. Still, we
> have more AT support than we would have had we not created an API to
> gain access to those applications.
>
> On both the Java and UNIX platforms, we developed our own rich support
> for AT. And on UNIX, we are both building our own AT, and being some
> combination of sufficiently important and relatively easy to develop AT
> for that we are attracting 3rd party AT to UNIX.
>
>
> > Because the Federal government (the customer) is asking for the
> > compatibility, perhaps they could help with the resources required for
> > number 3, with an SBIR-like grant program that AT and IT companies could
> > jointly apply for. (Not within TEITAC's scope, but could be offered as
> a
> > recommendation from our group).
> >
> > As to the question of whether an IT product must be compatible with ALL
> AT,
> > or just common AT: I agree this is a difficult problem, and one which
> the
> > formation of standards will help solve. To that end, we (AT) support
> the
> > establishment of interoperability standards. We welcome them. But we
> don't
> > feel they belong legislated in 508 where there is potential for them to
> be
> > mis-used, but rather as non-normative language that is ancillary to it.
> >
>
> Now it is my turn to sound like a broken record (or some more modern
> equivalent). We already have a set of technical standards in support of
> AT-IT interoperability. They are the "group C" items in 1194.21 and
> 1194.22 (see
> http://teitac.org/wiki/Web_and_Software:_Programmatic_exposure_of_informat
> ion
> for their enumeration and discussion). The problem is that they are in
> many cases inappropriate, and more importantly they are insufficient to
> the task of giving AT most of what it needs.
>
> So to me, the multi-part question is:
> 1. do we leave things in this known, poor state? or
> 2. do we only fix the most obviously broken parts, but otherwise
> leaving IT without technical guidance in how to best support AT (as it
> is asked to do in 1194.31)? or
> 3. do we enumerate the techniques we generally agree are good (as
> evidenced by the commonality in UI Automation, the Apple accessibility
> API, the Java accessibility API, the UNIX accessibility API, and WAI
> ARIA), recognizing that no enumeration is future proof?
>
>
> I rather clearly prefer #3...
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
> > -Randy
> > ATIA
> >
> >
> >> From: Peter Korn < = EMAIL ADDRESS REMOVED = >
> >> Reply-To: TEITAC General Interface Accessibility Subcommittee
> >> < = EMAIL ADDRESS REMOVED = >
> >> Date: Mon, 12 Mar 2007 15:04:16 -0700
> >> To: TEITAC General Interface Accessibility Subcommittee
> >> < = EMAIL ADDRESS REMOVED = >
> >> Subject: Re: [teitac-general] What is good enough to qualify for
> compatibility
> >> with AT?
> >>
> >> Hi David,
> >>
> >> As others have observed, this is a tricky issue. To me, it is also
> >> unlike anything else in Section 508.
> >>
> >> Requirements in 508 that say to industry "you must meet this standard",
> >> or "you must expose that information", or "you must meet this set of
> >> functional criteria" can be perfectly objective, clearly understood,
> and
> >> be 100% the responsibility of the product seeking to meet the 508
> >> requirements.
> >>
> >> Something that says, in effect "play well with others" is extremely
> >> difficult to deal with, especially if it is nearly that general a
> >> statement. Even variants of this - e.g. "play well with some others",
> >> or "play well with most others" - are only marginally better. Likewise
> >> "play well with the popular others".
> >>
> >> Because who is to say objectively where the fault(s) lie in failing to
> >> play well with another. Or to move away from these grade-school
> >> metaphors, who can say objectively that the reason my application fails
> >> to work well with their AT is because of a failing in my app or their
> AT?
> >>
> >> I understand and appreciate the challenge faced by agencies - Federal
> >> and State - and also users, who simply want a strong level of
> confidence
> >> that what they purchase will be accessible via assistive technologies.
> >> But unless and until we specify in significant technical detail how
> apps
> >> & AT are to interoperate with eachother - how they are to "play well"
> >> together - we have no way to even start making that objective
> evaluation.
> >>
> >> Compounded with this challenge is the fact that 508 sets forth
> >> requirements on IT, but not on AT. So we are really in the position of
> >> saying that IT must play well with AT - with AT being allowed (under
> >> 508) to completely uncooperative if it so chooses. If AT chooses to
> >> ignore me (perhaps my software application lacks sufficient market
> share
> >> to be worth any of their time), then I fail this test and am out of
> luck.
> >>
> >>
> >> This is why I think 508 should not state that IT must work with AT.
> >> Rather, I think it should set forth a measurable set of technical
> >> requirements for what IT must expose to AT, with additional ancillary
> >> material available that goes into even further detail for any given
> >> platform/OS (what we've discussed as "sufficient techniques"). Then IT
> >> can code to those specific technical standards. And if we have a short
> >> set of "sufficient techniques", I believe that market pressure will
> lead
> >> AT to support/use those techniques. Because AT does want to support IT
> >> - that is why it exists! But lacking a small set of recognized
> specific
> >> technical ways of supporting IT, we have the current, unsatisfying
> >> situation we are in now.
> >>
> >>
> >> Regards,
> >>
> >> Peter Korn
> >> Accessibility Architect,
> >> Sun Microsystems, Inc.
> >>
> >>
> >>
> >>> Some people think compatibility with just one AT is sufficient. And
> they
> >>> will argue that Subpart C did not explicitly say that it had to work
> >>> with more than one AT. This goes to product brands (e.g. JAWS and
> >>> Window Eyes) as well as product types (e.g. refreshable braille
> displays
> >>> and screen readers).
> >>>
> >>> To stretch this even further, an IT developer could argue that the IT
> is
> >>> perfectly 508-conformant through compatible design, even though it
> does
> >>> not work with any AT on the market currently, because it could work
> with
> >>> AT if the AT manufacturers made the AT differently/better. Or would
> you
> >>> disagree with that? Those of us on the front line providing technical
> >>> assistance need this to be clear in the final standards so that our
> >>> answers do not sound like they arbitrarily came from Access Board
> staff.
> >>> I want something in writing to put my finger on.
> >>>
> >>> I skimmed the wiki and archived email discussions but did not see this
> >>> directly addressed. This is one of those issues that have come to the
> >>> Access Board many times and which need to be resolved in the refresh
> 508
> >>> standards. We would like the TEITAC to address it. Would it be an
> >>> interoperability sufficiency issue?
> >>>
> >>> This is tied to a discussion in January about problems with one
> version
> >>> but not another version of a product. Perhaps all of these variations
> of
> >>> the issue (versions, brands, AT types, etc) could be handled in one
> >>> spot.
> >>>
> >>> David Baquis
> >>> Accessibility Specialist
> >>> U.S. Access Board
> >>> 1331 F Street, NW, #1000
> >>> Washington, DC 20004
> >>> 800-USA-ABLE; (202) 272-0013 (voice)
> >>> www.access-board.gov; = EMAIL ADDRESS REMOVED = "Leading the way
> to
> >>> excellence in accessibility"
> >>>
> >>>

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