Thread Subject: Re: Starting discussions onthe AccessibilityAPI proposal

Return to this mailing list's archives

From: Andrew Kirkpatrick
Date: Thu, Dec 21 2006 3:40 PM
Subject: Re: Starting discussions onthe AccessibilityAPI proposal

Thanks Randy and Jessica,

Some comments

1. To some extent, the set of APIs begins to readmore like a set of
design specifications. There are many ways to achieve an end, and we do
not want to stifle innovation just because this is the way things are
currently done. We have learned in government regulatory standards that
it is better to define the end result, not the means for achieving the
end result, that way, as new technologies develop, and as our
understanding of technology evolves, we can freely and easily as an
industry decide to modify and improve how the ends are achieved.

As Peter stated, in his earlier response, we have no desire to stifle
innovation either. However, many of the standards that currently exist
were created based on how things were currently done and standards that
we're discussing now are also frequently discussed in the context of
what is currently possible. The desire is to create a frame that we can
exist within today (or when the update to 508 goes 'live') and that we
can work within moving forward. There is no desire to limit the
creation of creative solutions to deliver functionally equivalent
accessibility.

2. In light of the dramatic pace of technologychanges, if an IT
manufacturer/developer has met this set of APIs, compliancewith these
APIs does not guarantee that the end products are accessible.

No, nor does meeting the current standards in 1194.21 accomplish that.
I'm not describing an accessibility API as a magic bullet, just as a
basic roadmap to guide software and OS developers in the right
direction.

3. Additionally, as new technologies develop, theseAPIs will likely
be missing provisions to address new and emergingtechnologies, and this
set of APIs will be out of date quickly, and willpose interoperability
problems with respect to new technologies.

This is basically the same as point #1, correct?

On the flip side, having standard expectations for Accessibility APIs
will help developers of new technologies. If someone develops something
that radically different from what exists today they may need to extend
an API or to evaluate the product under the functional performance
criteria instead. This proposal is not for a specific API that will be
out of date, it is for a generalized notion of what constitutes the core
set of information that accessibility APIs should contain.

4. The regulatory process cannot keep up with theneeded changes at
the same rate as a traditional standards body or generalindustry
practices. If we lock into one set of APIs, companies may be unwilling
(or legally unable) to make changes in accordance with new developments
to utilize new and developing technologies.

Just to restate this point, the proposal is not defining an API or
blessing a set of APIs, but defining the core set of information that is
needed. I believe that this will ultimately simplify the process for
developers and AT in establishing support for consumers of AT.

This topic is difficult to get a handle on - based on
Randy/Jessica/Sean/Travis's responses I think that there is enough
interest in the theory (even if intermingled with reservations of
varying quantities) that it would be worth suggesting to the larger
Teitac group that we take a slot of time at the February meeting to
discuss the benefits and challenges associated with this proposal.

AWK