Thread Subject: Re: Accessibility API 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: David Poehlman
Date: Sat, Jan 20 2007 3:15 AM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Robinson, Norman B - Washington, DC: "Re: Accessibility API proposal"
- Previous message in thread: Randy Marsden (Home): "Re: Accessibility API proposal"
- Messages sorted by: Author | Thread | Date
A couple of thoughts.
I think working this in such a way as to promote innovation and
continued evolution is a good thing. I agree that APIs alone are not
sufficient.. Perhaps the standard should contain the api with
additional language supporting future work and bee made a living
document not subject to the normal chanels of change but on a faster
track so as to keep up with developments.
As I see it, there are three possible positive outcomes.
1> software works on its own and can comply.
2> software works with existing apis et al.
3> aT is developped with our API in mind so that when products are
built, they can more rreadily be made to fit the requirements of AT
and It which is not AT to work together. Oh, Is there ever a time
when IT is AT?
AS far as AT its self is concerned, the only way we can avoid
confusion as to whether it meets 508 is to special case it and for
that we'd probably need a base line approach. I don't see an
equitable way to exempt a class of product based on its stated
function. If we do that, AT for the blind suddenly becomes
acceptable if it cannot be operated with one hand or if it blacks the
screen... I'm not saying that we need to go to extremes here, but we
need to be careful of our approach.
On Jan 11, 2007, at 11:21 AM, Randy Marsden (Home) wrote:
I think itâs time for us to weigh in on this subject. First, I agree
what Gregg says below. Here are our additional thoughts from the
perspective of an AT manufacturer:
> * We like Accessibility APIâs (but not necessarily in 508). In
> fact, we have
> been advocating for them for years, and have worked extensively
> with the OS
> manufacturers to put them in. So, they are not something we are
> afraid of â
> in fact, we helped design them and are a large part of why they
> exist! Our
> concern is that if we define a minimum set in 508, then that may
> become all
> that people work toward or support. That wouldnât be a good
> thing. But there
> may be ways we can word things such that there is room for changes
> growth to address that concern. Weâd like to explore that, because
> we do
> indeed see value in defining a set of standard APIâs.
> * We like cooperation. Defining a minimum set of APIâs potentially
> sets up a
> circumstance where an IT vendor can say âhey, we met the minimum â
> so weâve
> done our part. It must be the ATâs fault itâs not workingâ. AT
> could answer
> âhey, we did tooâ. Then the finger pointing begins. The reality is
> even with
> APIâs, there is usually technical tweaking and cooperation required
> the IT and AT to make it all work. Speaking on a technical level,
> APIâs are
> very helpful, but not necessary a magic cure for all compatibility
> Weâd prefer to see 508 create an environment that encourages
> cooperation to
> help guarantee interoperability. Some companies (HP, Microsoft,
> Apple, etc)
> actually have special developer programs for AT vendors that are
> very helpful.
> Thatâs an example of what weâd like to see 508 encourage.
> * We understand the issue of market power. We know there are times
> procurement of an IT product can be inadvertently held up by AT,
> and that
> thatâs not good. Thatâs not in anyoneâs best interest â certainly
> not the AT
> companiesâ. We would much rather generate revenue from the sale of
> than spend time customizing things. But there is not always a
> business case
> for AT companies to make their products work on all platforms â
> even with an
> API set in place. Surely we canât tell an AT company they must
> make a product
> that they arenât going to sell any of, simply so an IT company can
> win a
> federal contract. So, there are valid concerns on both sides. We
> need to
> talk about it and figure out the best solution. APIâs may be part
> of that
> solution â but we donât believe they are the single magic answer.
> * We donât mind accountability, but it needs to make sense. In
> many cases,
> the provisions of 508 would defeat the purpose for which the AT is
> Often, AT is intended to serve a specific disability group, and is not
> supposed to be accessible for all. Take, for example, an eye-
> tracker ... if
> that was subject to 508, it would technically need to be accessible
> to someone
> who is blind. Makes no sense, right? Every time an AT company
> tried to sell
> this piece of equipment to the federal government, an argument and
> justification would need to be made explaining why it should be
> exempt from
> 508. Thatâs a lot of red tape for both the procurement officers
> and the
> vendors for something that is obviously not applicable.
> * We are motivated by compatibility. Itâs important to understand
> that the
> primary motivation for AT that is derived from Section 508 is the
> for enhanced compatibility with IT. Theoretically, that means our
> work better and weâll sell more of them. For many AT companies,
> government purchases represent only a small percentage of their
> business, so
> even if there were requirements for AT put in 508, they may not
> have the
> desired effect. Rather, if 508 sets up an environment that encourages
> interaction and collaboration between AT and IT, weâll be all over it.
Randy & Jessica
> From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
> Reply-To: TEITAC Web/Software Subcommittee
> < = EMAIL ADDRESS REMOVED = >
> Date: Wed, 10 Jan 2007 23:45:59 -0800
> To: "'TEITAC Web/Software Subcommittee'" <teitac-
> = EMAIL ADDRESS REMOVED = >
> Subject: Re: [teitac-websoftware] Startingdiscussionson
> Good thoughts.
> A couple more
> - conformance to an API isn't sufficient if there is no AT or the
> can't get or can't use it. For example - conformance to an API for ATM
> software will provide no access since they system is closed. So API
> - I actually don't think APIs should be required (since there are
> APIs and we don't want to freeze innovation. Also they aren't
> by themselves.
> - where I think APIs come in - is that the existence of APIs can
> reduce the work of both AT and IT vendors in making products work
> But they still have to test them and make sure they work together -
> even if
> they both build to an API. Anyone familiar with standards is also
> familiar with plugfests and other similar interoperability events
> people who all built to the same specs get together to test and
> actually get
> the 'compatible' products to work together. They are always highly
> instructive - and the winners are people who worked together to get
> to work - and a few luck people. Building to a spec and not
> testing rarely
> works in any industry much less one as complex as IT.
> So APIs are indispensable in helping us to move forward. But they
> guarantee interoperability and therefore access - without actually
> to make sure things work.
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>>> From CES
- Next message in Thread: Robinson, Norman B - Washington, DC: "Re: Accessibility API proposal"
- Previous message in Thread: Randy Marsden (Home): "Re: Accessibility API proposal"