Thread Subject: Re: Startingdiscussionson theAccessibility APIproposal

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: Sun, Jan 07 2007 8:15 PM

Greetings,

I think that Debbie Cook has hit a critical part of the problem
we have with assistive technologies.

Testing with assistive technology has been a cornerstone of
usability testing many of the Section 508 technical standards.
Sometimes, agencies even specify and rely on a specific vendor's
implementation to determine accessibility for their agency, tied closely
to how they interpret Section 508 compliance. I can imagine this is
confusing to some vendors when they think they have satisfied one
agencies specific requirement, can demonstrate a particular product
(electronic information & technology; E&IT) works with a specific
assistive technology, and yet they might not be strictly following the
Section 508 standards, thus not considered compliant by other agencies
that rely on a different vendor's assistive technology or that judge the
solution based on strict technical compliance, no matter what can be
demonstrated with assistive technologies.

We must somehow get the assistive technology vendors to use
specifications they can rely on and then we must insist their products
meet these standards. This will require validation and also require
vendors to test they can provide access against known standards (e.g.,
test a screen reader against all ACID2 test cases
(http://en.wikipeidia.org/wiki/Acid2).

This is also tied to the valid code or validation issue. We need
a way in which the vendor can test their implementation against a
standard and therefore be reasonably assured their product will work
when it encounters different content. The problem for us is that the
vendors do such a good job of providing access, they build software that
works around the specific deficiencies of another vendors product. They
build custom scripts and the end-user simply experiences a wonderful
product that provides access. I'm not against access, but when this
approach is taken we will always encounter the inherent problems of
tying a product to a specific implementation version that isn't a
standard. We will have to upgrade to the latest version of the assistive
technology. We will have limited choices of assistive technology.

The concepts expressed in 1194.5, Equivalent Facilitation also
makes it imperative that we consider the specific programming techniques
and standards (application programming interface or APIs). So your
content works with your screen reader. Consider what happens if tomorrow
an updated version of a PDF reader that everyone uses includes its own
screen reader. Lets pretend it doesn't work with my screen reader. I
think it is accessible because I can demonstrate accessibility - but
you'll have to use my own reader. And I don't support your other
operating system. And I require admin rights to install. And you must
get a encrypted key to use the product - for free of course - so I can
ensure digital rights management. Now consider what happens if each and
every office application on our computer's desktop does the same thing.
This works for web browsers too! Need I go on?

I think it may be appropriate to make specific well known API or
toolkit _recommendations_ a part of the Section 508 refresh. I think it
is fair to state since the Section 508 Technical Standards are just
that, we make recommendations such as contracting agencies should
consider requiring E&IT validation against known standards. Section
508v2 should clearly state contracting vehicles should request "standard
compliant content" somewhere. It isn't as if specifying Microsoft Active
Accessibility (MSAA;
http://en.wikipedia.org/wiki/Microsoft_Active_Accessibility) version 2.0
as a minimum for developing MS Windows software will harm accessibility
on a MS Windows platform! (What we do when MSAA is to be discontinued or
the MS Windows APIs themselves change is another matter I won't address
here.) We need the same for web content.

I know this issue is debated by many reasonable people, however
just because we can have accessible content that doesn't meet the
validation, people dismiss the idea we should require validation.
Validation works when it can be tested. I've advocated the Section 508
provisions for web content and Internet applications are simply a subset
of the software standards. Well, for most of the software standards the
actual programming languages themselves have very strict requirements
for building applications - the API - that aren't simply something you
test against but you must use or else your application won't compile and
won't run! Coding purest will see my crude description for what it is,
the important part is I'm speaking about compiled programming languages
(http://en.wikipedia.org/wiki/Compiled_language). Summary: the process
requires correct _valid_ code. The process which is used to build the
software _validates_ the code before it ever can be used by the
end-user.

In web content and Intranet applications use document markup
languages. Vendors build content but don't necessarily validate the
implementations. A short list of known standards for web content are
XHTML 1.0 Strict, CSS 2.0, and SVG 1.1. We should require this as a
recommendation for all web content in the refresh. (XTML 1.0 is from
2000 - 6 years ago!) And beyond that specific reference in the refresh,
we need to push the vendors to test their assistive technology against
the test cases (e.g., ACID2 tests for HTML and CSS).

Sorry for such a long post. There are many related issues with
API issues that perhaps belong in the software discussion, but are
related to web (as the web browser is, in fact, software!) and important
when web applications are being created without the strict requirements
of compiled code or validation. For applications on the desktop, there
are probably a list of resources we could develop for each and every
operating system (I use AmigaOS, Linux, OSX, Solaris every now and then,
and MS Windows - there is more than just MS Windows users that need
access!). Should we do this as part of the refresh? Is it appropriate?

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 Debbie
Cook
Sent: Friday, January 05, 2007 12:27 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal


One of the fundamental problems we currently have is that because AT has
no
requirement to comply with any standards in order to work with IT, the
It
may complay nd not work with any AT. So, just as IT companies go beyond
the
minimum to compete so should AT. And frankly, while it's reasonable to
debate the merits of any components of a standard API, I think it's
highly
desireable as a baseline for both AT and IT in terms of
interoperability.
What now happens is that a given IT product is compatible with one AT
and
not another. It is all too common that the bottom line for our IT
procuremens is that they must work with X or Y AT. That's not good for
the
consumer or for the smaller AT vendor.
----- Original Message -----
From: "Eric Damery" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee"
< = EMAIL ADDRESS REMOVED = >
Sent: Thursday, January 04, 2007 1:46 PM
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal


Jessica,

Very well said.

Just to follow up on this line of thought, another concern when making
the API the "gold standard" should be what the incentive will be for AT
to do anything beyond the API, if it becomes the measurement for
procurement. As I understand it, a limited API could make it easier to
swallow for I T but at the same time, stifle smaller AT companies from
being able to help achieve access for users if it requires anything
beyond it. I suspect the same will be true for AT designed in at the
system level.

Regards,
Eric Damery

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jessica
M. Brodey
Sent: Thursday, January 04, 2007 4:21 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

Jim:

Speaking as a policy wonk in lay terms, I think that the common
misunderstanding here is that use of an accessibility API equals
accessibility. Just because there is an accessibility API does not mean
that every piece of AT automatically works all of the time - it just
increases the odds of existing AT working with new products. But,
sometimes new technologies come with new features. If the AT did not
take into account those new features or capabilities, support for those
features still needs to be built in. An accessibility API makes it
easier to build in support for those features, and makes it less
burdensome for the AT vendors to do so (and means supporting those
features should be more standardized), but it is not always automatic.
Also, as I understand it, just because a company uses the accessibility
API does not mean it implements the API in exactly the same way as
another company, thus, it is possible a piece of AT may not work
perfectly with one product that uses the accessibility API but may work
perfectly with another, and thus it may not be fully compatible with
every product. So, the verdict is that an accessibility API could be
useful, could improve things, but does not mean that compliance with the
API will equal access.

Another problem is that adopting an accessibility API that is the "gold
standard" today may quickly be old and out of date in 6 months or a
year.
While we are in danger of this for many aspects of 508, it is
particularly worrisome for how AT interfaces with IT, because it could
stifle the growth and expansion of new AT, particularly if the
accessibility API becomes the excuse or justification . . . "well, we
used the accessibility API, we don't have to be compatible with ACTUAL
AT." At some point not too far off, because the API won't be able to
grow and evolve once put into regulation, what started off as a means to
improve accessibility could actually become the one bar to providing
real access.

Jessica Brodey

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
Tobias
Sent: Thursday, January 04, 2007 11:01 AM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Startingdiscussionson theAccessibility
APIproposal

Your concerns are justified, but you have the concepts backwards.
Thinking in terms of an accessibility value chain guarantees that we are
thinking of all the steps required to give the end user access.
Separating the regs by narrow targets, one product or industry at a
time, ignores the need for both technical and informational
interoperation.

There is no getting around the problem of assigning responsibilities to
the "proper"
parties. Luckily 508 burdens the purchaser, who has the best view of
the entire chain, from OEM-type product to developed product to
installed product to user and administrator. In theory. The problem
remains one of information flow rather than raw technological power, as
your example indicates -- Gregorian did not work closely enough with the
AT community.

But that raises another troubling point: why is the Accessibility API
not sufficient? If Gregorian builds its software correctly, why is
additional action required by AT vendors?
If Gregorian cannot sell to the feds until one or more AT vendors acts
to make the new product accessible, isn't that an imbalance of market
power? I thought the whole idea of the Accessibility API was to
eliminate that problem.

Maybe I'm misunderstanding something....


> -----Original Message-----
> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, January 04, 2007 1:52 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Starting discussionson
> theAccessibility APIproposal
>
> Why value chain is good concept - but we need to be very careful about

> its use in regulatory standards.
>
> I really like the accessibility value chain concept as a way to
> understand this - and to point out the way things work together.
>
> But I worry about it in a discussion of how to structure our
> standards. And I don't think we should structure our standards around

> it. If we did then we would only require that software companies
> "enable" there software to be accessible - but they would have no
> responsibility to actually make sure that there was AT that did work
> with their software and did make it
> accessible. The result is that in fact it would be "meet
> accessibility
> standard" but be unusable by anyone with a disability.
>
> Take the following example.
>
>
> The Gregorian Software company creates a marvelous new media
> technology. It is new, different and extremely compelling web
> software for shopping and transactions using a simulated person and
> live environment over narrow
> bandwidth. They implement it with an accessibility API but
> no one uses the
> technology (of course) til its release in Sept 2007. At its
> announcement it
> is adopted by Amazon, a slew of banks, etc. AT vendors
> begin working with
> it but it will be a year or more before they can get up to speed (sort

> of like when dos went to windows) but this technology spreads at
> Internet speed because it is free downloadable plug in for most users.
>
> Suddenly these sites go black to AT users. But if we write out
> guidelines such that the sites and the Gregorian software company can
> say their software meets access standards, without actually requiring
> them to be supported by real live AT that is out there - and available

> to users.
>
> In fact AT vendors will remember the days before we required software
> to
> actually work with real AT. Software would come out with
> an accessibility
> API but AT vendors were not able get access to it and had very poor
> support
> from software vendors even after release. Only when the
> software was
> required to actually work with real AT did the vendors invite and
> support and even court AT vendors in the same way they invited,
> supported and courted other software and hardware vendors (for
> compatibility) when they released something new.
>
> So I think the "accessibility value chain" is a very important
> concept. But I don't think we should base our standards on it.
>
> I think that something is accessible if it can be used by real people
> who have disabilities, not just that it theoretically could be if only

> those other people had done their job.
>
> Accessible - means that it can be used by people with disabilities.
> That means it is either directly accessible. Or that it is accessible

> using the AT that the person with a disability has or can reasonably
> get (or in the case of the government - for its employees - AT they
> are given). For public websites, it would be the AT that the public
> at large has, can reasonably get, or is given.
>
> Any other definition of accessibility defeats the purpose the
> legislators laid out in creating 508. that is that people with
> disabilities could actually use the E&IT in the government alongside
> everyone else - and when it was purchased (not sometime in the future
> - if someone else does their job).
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > Tobias
> > Sent: Wednesday, January 03, 2007 9:35 AM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] Starting discussions on
> > theAccessibility APIproposal
> >
> > 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