Thread Subject: Re: Starting discussions on the AccessibilityAPI proposal
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: Randy Marsden
Date: Wed, Dec 20 2006 2:25 PM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Peter Korn: "Re: Starting discussions on the AccessibilityAPI proposal"
- Previous message in thread: Gregg Vanderheiden: "Re: Starting discussions on the AccessibilityAPIproposal"
- Messages sorted by: Author | Thread | Date
ATIA has had a chance to review the minimum Accessibility API proposal that
has been floated to this Subcommittee. We agree with MicrosoftÂ¹s recent
comments. ATIA is also concerned that the minimum set of Accessibility APIs
may not be appropriate for inclusion in Section 508. Here are a few of our
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.
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.
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.
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
ATIA is concerned about articulating the current Â³bare minimumÂ² standards.
If all the operating systems already have the APIÂ¹s listed in the minimum
set, we are not certain that including these APIs as requirements in this
manner is the best course. Our experience is the bare minimum can be a
negative influence when enacted in regulation. There is a danger that once
a minimum level is set for the APIÂ¹s, that then becomes the Â³standard,Â² and
nothing more will be permitted and innovation and advancement will be
stifled. More than that, it becomes difficult to throw out APIs once they
are outdated. Currently, industry has the final Â³say-soÂ² with respect to
APIs Â what stays, what goes, and a simple Â³meeting of the mindsÂ² and
discussion can change that. Unfortunately, regulatory processes are not
that simple. Consequently, regulations must be written in a manner that can
allow for industry changes and evolutions, and ATIA does not believe this
minimum API set accomplishes that end.
Nevertheless, there are some benefits to this proposal. Perhaps it can be
used as a recommended best practices guideline, or some other document as an
exemplar of one current means of meeting the standard. It can be utilized
in a more Â³unofficialÂ² manner that can easily be discarded and or updated as
and when it becomes out of date. For example, this document can serve as a
guideline for emerging devices and operating systems that may not already
have the minimum set of APIs. It also has the potential benefit of helping
mainstream application developers know what APIÂ¹s they should be supporting
in their product, to maximize its compatibility with AT. But again, we feel
those benefits could be achieved in a more flexible manner outside the
confines of Section 508.
Randy & Jessica
- Next message in Thread: Peter Korn: "Re: Starting discussions on the AccessibilityAPI proposal"
- Previous message in Thread: Gregg Vanderheiden: "Re: Starting discussions on the AccessibilityAPIproposal"