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: Randy Marsden (Home)
Date: Thu, Jan 11 2007 9:35 AM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: David Poehlman: "Re: Accessibility API proposal"
- Previous message in thread: firstname.lastname@example.org: "Re: Starting discussions ontheAccessibilityAPIproposal"
- Messages sorted by: Author | Thread | Date
I think itÂ¹s time for us to weigh in on this subject. First, I agree with
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 and/or
> 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 between
> 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 issues.
> 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 when
> 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 product
> 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 developed.
> 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 potential
> for enhanced compatibility with IT. Theoretically, that means our products
> work better and weÂ¹ll sell more of them. For many AT companies, federal
> 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'" < = 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 users
> 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 multiple
> APIs and we don't want to freeze innovation. Also they aren't sufficient
> by themselves.
> - where I think APIs come in - is that the existence of APIs can greatly
> reduce the work of both AT and IT vendors in making products work together.
> 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 where
> 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 things
> 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 don't
> guarantee interoperability and therefore access - without actually testing
> to make sure things work.
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>> >From CES
- Next message in Thread: David Poehlman: "Re: Accessibility API proposal"
- Previous message in Thread: email@example.com: "Re: Starting discussions ontheAccessibilityAPIproposal"