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: Fri, Jan 26 2007 11:50 AM

Gregg,

Thanks!

I'm trying to constrain my response to the subject, that being
Accessibility Application Programming Interface (API) (specifically
software and not hardware), however your example is worth interpreting
as I think I have the responsibility to be clear in my posts.

1. Automated postal stations have touch screens (hardware) that
interface with the driver software running on the operating system.
2. Tactile controls running on the same system are keys or in
effect a keyboard (hardware) that interface with the operating system.
3. Voice output is actually designed into the software
application itself and directed to the earplug or speaker (hardware) via
the operating system.

My point is that those are _hardware_ or physical requirements
that should be in the refresh, but I don't like the term "closed, self
contained" as the category or labeling of such doesn't help us as we get
to many integrated devices. The concepts fail and people reading and
interpreting the technical standards when creating devices with physical
interfaces (e.g., touch screens, keys and keyboards, connectors) are
better served by being told about the functional requirements for
physical hardware and not having to ask "Is this closed? Is this
self-contained?" So I suggest the refresh simply consolidate all the
technical requirements for hardware in one section and do away with
"closed, self-contained".

Back to concepts of an accessibility API. I won't ever use API
to refer to hardware, as I think it is purely a term related to
software. We could use the term "interfaces" but then we could fit
hardware back into the discussion (e.g., hardware interfaces as a term)
so perhaps "software interfaces" is most clear and I should use that
from now on.

What I mean by providing access via operating system functions
is that when manufacturers design software to work with hardware they
choose the appropriate operating system for their application. The
operating system provides a level of accessibility and abstraction to
the software so the vendor doesn't have to create their own operating
system functions. Most operating systems provide abstractions for
accessibility functions through the specific software interfaces to
enable functions such as on-screen keyboards, visual alerts, captioning,
and event updates (e.g., interface windows opening, windows or software
views being refreshed such as a web page reloading) via accessibility
APIs.

From a programming perspective, if I create window for my new
web browser, you may see a web browser, but it is a window, created by
the operating system. It usually has the expected "Close Window",
"Maximize Window", "Minimize Window" widgets. The API that allows this
also has information such as the window name (e.g., Mozilla Firefox)
obtained from the same API used that a screen reader would use to voice
the name of the window. And when the first window is opened (the program
starts) the screen reader gets the event, through the API, thus knows to
read the event. What I'm saying, relevant to the Section 508 refresh, is
that we can consider well-known accessibility interfaces as functional
specifications for the refresh. We might find value in requiring
operating systems to meet all the functional specifications to be
considered Section 508 compliant. In terms of suggesting we should
require this in the refresh, I don't see how we can do anything else,
other than to say the existing technical standards for software and
operating systems already describe functional requirements, but we don't
have a clearly defined statement that says "Yes, the operating system
has to support accessibility or else your software would have to
(re)create all these basic functions".

Finally to answer your question "How do you provide access for
blind people to touch screen kiosks using built in OS features?" I say
that I design my software (in our example the interface running on the
automate postal stations) using the frameworks provided by the operating
systems accessibility interfaces. When I expect the physical buttons to
provide an enter-key event I could also state "press any key or touch
the screen to continue". For that physical function I have the software
provide interaction using the standard interface events, so that if I
enabled visual alerts I could get flashing and the error beep. I could
get the vendor to show us which software development framework they
used. Otherwise I'd have to code both of those into each and every
screen myself (as a programmer). Also, by using things like the
operating system accessibility software interface I can do things *I*
didn't program in such as later enabling an on-screen keyboard (since my
program only expected key entry, who cares how it gets the key
information) or perhaps enabling bluetooth keyboard access so I can use
my own keyboard. This includes enhancing and adding on to the system
which is where I see failure and risk; most systems I've evaluated as
Section 508 compliance have sometimes fallen out of compliance because
of updates, not due to entropy.

It is also important to know in our hypothetical versus
real-world examples the automated postal station are self-voicing but
there is not a screen reader. The vendor has to record voice events and
voice descriptions for each and every screen. It is laborious, tedious,
error-prone, doesn't dynamically update with content changes, and
probably isn't the best way to go about implementing the system. But
that is how it is done today and I've taking this into consideration in
speaking to the concepts of an accessibility software interface or
accessibility API.

In terms of actionable events I'd like to see something that
states operating systems must provide accessibility APIs that meet the
Section 508 functional performance criteria (currently Subpart C). I'd
argue that is already required today as an operating systems are
software thus 1194.21 applies, however no where does it require that the
OS software provide accessibility information to _other_ software. It is
simply the best practice, has been implemented as such on multiple
operating systems, but I think the refresh could make this relationship
clear without adversely impacting industry and doing so would further
the cause of accessibility.

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 Gregg
Vanderheiden
Sent: Friday, January 26, 2007 12:08 AM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Accessibility API proposal



Example? - How about the post offices automated postal stations.
They
have touch screens but also tactile controls and voice output that allow
you
to access all functions from the tactile controls. (you can also use
the
same controls near the front of the system to control the APS visually
(without audio) and without using the touch screen).


Question: Could you explain what you mean by providing access via OS
functions? For example , how do you provide access for blind people to
touch screen kiosks using built in OS features?

Thanks



Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Robinson, Norman B - Washington, DC
> Sent: Thursday, January 25, 2007 1:38 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Accessibility API proposal
>
>
> Gregg,
>
> Could you please give me an example of direct access?
> For all our kiosk implementations the accessibility is
> provided via the operating system functions or software that
> relies on the operating system functions.
>
> 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 Gregg Vanderheiden
> Sent: Wednesday, January 24, 2007 11:49 PM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Accessibility API proposal
>
>
> The application could of course provide direct access, as you
> mentioned in
> another email. Then the OS would not be relevant. On Kiosks for
> example,
> accessibility of the OS is not that relevant. But built in
> accessibility would be.
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Robinson, Norman B - Washington, DC
> > Sent: Wednesday, January 24, 2007 5:01 PM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] Accessibility API proposal
> >
> >
> > 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