Thread Subject: Re: Accessibility API proposal

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: Robinson, Norman B - Washington, DC
Date: Wed, Jan 24 2007 4:05 PM

I'd say the real issue is that the _operating system_ itself
must be capable of supporting accessibility. The real test for an
operating system is if it provides APIs that support use by software in
ALL of the functional performance criteria of 1194.31. If it doesn't,
then the operating system isn't accessible and no software running on
that operating system will be accessible.

It is a chain. The operating system must support accessibility
and provide a standard way for software (an API) to provide
accessibility. The software can then be developed to meet the technical
standards for accessibility (software standards) and in specific content
issues (web content) that content can meet the specific standards
because the software (web browser) provides those features inherited
from the operating system.

Regards,


Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of David
Poehlman
Sent: Saturday, January 20, 2007 5:09 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Accessibility API proposal


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.
and:
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.

Thanks!

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
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
ATIA

>
> 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
> theAccessibilityAPIproposal
>

> 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
> conformance.
>
> - 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
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>>> From CES
>
>
>
>

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