Thread Subject: Re: Starting discussions ontheAccessibility 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: Jim Tobias
Date: Wed, Jan 03 2007 8:55 AM

Sean Hayes wrote:

"Firstly I agree that there is a problem that needs adressing
here, which is the equitable division of reponsibility on
accessibility between each entity involved in delivering a
software product. However, as we are all aware, this is very
difficult problem given the manner in which modern software
is produced, which in most significant products involves
cooperation across multiple organisations, not only the
software product developer, but OS vendors, hardware vendors,
AT vendors and middleware vendors among others. In some cases
standards or industry practice already exists around these
interfaces, and in some cases it doesn't."

I would like to take this opportunity to develop a little further the
concept of an
"accessibility value chain", which Sean refers to indirectly. I believe
that clarifying
these responsibilities is at the heart of "modern" accessibility, because,
as Sean
notes, modern software requires cooperation across multiple organizations,
many of
whom have only indirect relationships.

I would like to posit that the nature of this technical cooperation has
three
distinct elements or phases: capability, implementation, and preservation.
By
"capability" I mean that the software component contains all the features
necessary
for accessible use or development. Examples are the ability to add a text
description
to an image in a web development tool, and the ability to record and play
back Baudot
files in a voice mail platform. By "implementation" I mean that the
capability has
actually been used by the next link in the chain. That is, the web
developer has actually
added a text description to an image, and the telecom manager has actually
set up a
voice mailbox so a Baudot TTY user can receive messages. By "preservation"
I mean that
the next link in the chain is required not to interfere with the
accessibility feature already
in place further up the chain. For example, a digital cable system must not
strip the captioning
information from a captioned video program during transmission.

Most of the relationships in the chain are capability-implementation ones,
especially for
web and software. Thus the current 508 requires software to inherit system
display settings, use
standard OS text presentation techniques, etc.

I think this formulation may clarify for us where we want to go. For
example, we have mentioned
adding OS requirements. That is, current 508 requires "downlink" software
to honor OS accessibility
features, but it doesn't require OSs to have those features. I think we may
agree on adding such
a requirement, especially if we use today's common OSs as models rather than
dreaming up new
features OSs don't have yet.

Another point that may meet more resistance, but seems clear to me, is the
utter inseperability
of content from software once we agree that there is an interlocking set of
relationships in the
web/software arena. In the examples of the web page and voice mail system I
used above, how can
the tools be abstracted from the content? My thinking here is not very well
developed, so I
look forward to a dialogue.

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