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: Jessica M. Brodey
Date: Thu, Jan 04 2007 10:20 PM

Peter:

ATIA agrees that there are already aspects of an Accessibility API in 508.
We are opposed to creating and labeling something an "Accessibility API,"
enumerating it exactly in 508, and thus running the risk that companies can
say "hey, I used the accessibility API so I am 508 compliant" without actual
interoperability with AT. We want to be clear that while we think moving
towards incorporating an accessibility API is a good thing, it may not be
the lone solution to full interoperability, nor does an accessibility API
alone equate to actual access, and it should therefore not be used as the
measure for 508 compliance. We are also not certain that an accessibility
API expressed as such belongs in 508, which is a regulatory standard, as
opposed to in an industry standard.

ATIA would rather see enumerations written in broad brush strokes, not the
specifics that would indicate "use this particular accessibility API." I
apologize for not speaking to the specific language and sections as I am a
policy person, not a techie, but if you equate this to the world of the
Internet, we do not want to structure the regulations in a manner that would
say the equivalent of "supports Java version x," or even spell out all the
components or provisions in Java (without actually specifying it) that make
it obvious which version of Java we are pushing to support. We would rather
spell out characteristics that would allow a company to provide Java support
in satisfaction of that provision, OR could allow a company to go another
route and still satisfy the requirements of the regulation, or in three
years switch to Java version x2 without violating the regulation. I
understand that approach is sometimes frustrating for techies who often want
it to be spelled out in black in white. Unfortunately, it is the same
techies who also want the flexibility to innovate, and not be hemmed in when
the law is so specific that it prevents them from diverging. We need to
find a happy medium here . . . where we can include the elements of an
accessibility API to get at some of the benefits without nailing down such
specifics that we are locked into only one version of an accessibility API
that is too rigid and cannot evolve.

We need to focus on the end results - what we want to be able to achieve,
not the means of getting there. The distinction you pointed out, Peter, is
that while the descriptions in 1194.21(c) may comprise aspects of an
accessibility API, it does not dictate the nature of the accessibility API -
it is focused on the result of the access, not the means for providing the
access. Perhaps we can determine what aspects you feel are missing from the
existing provisions that are critical to an accessibility API, and write
them in language consistent with 1194.21?

Again . . . we think implementation of an accessibility API is a best
practice, and perhaps can be used/publicized in other aspects of this
process as a guide to understanding how to comply with the 508 requirements.

Jessica

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: Thursday, January 04, 2007 11:38 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

Hi Jessica,

> ATIA's position is that an accessibility API has a role, but it is in the
> business venue, or in the standards venue, not the regulatory venue. If
we
> want to include aspects of the accessibility API into 508, it should be as
> Sean Hayes from Microsoft has advocated. We are concerned about an exact
> and precise list that is finite and unable to evolve without reconvening a
> new panel and a new refresh. We see an accessibility API as more of a
good
> business practice that is the best way to meet some of the specifications
of 508, but which accessibility API may change and evolve over time.
>

508 already includes aspects of an accessibility API. The seven
provisions enumerated in
http://teitac.org/wiki/Web_and_Software:_Programmatic_exposure_of_informatio
n
are existing places where 508 describes the programmatic information
that IT shall provide to AT. The current language doesn't call this
portions of an "accessibility API", but language like "focus shall be
programmatically exposed so that assistive technology can track focus
and focus changes" in 1194.21(c) aren't too far away from that.

And I think ATIA would agree with me that the seven provisions in
question constitute an insufficient set of information from which AT can
accomplish their task. Yet these seven represent "a list that is finite
and unable to evolve without reconvening a new panel and a new
refresh." In fact, it is the very process of refreshing these seven
provisions that gave rise to the accessibility API proposal - a much
richer enumeration of things we know are needed, and in support of which
the evolving, platform-specific accessibility APIs like UI Automation
can be used by IT vendors to interopreate with AT.

If ATIA is opposed to a finite list, then what does ATIA propose we do
with finite list we currently have - the seven provisions enumerated
above?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> Jessica
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Lybarger,
> Barbara (MOD)
> Sent: Thursday, January 04, 2007 6:14 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
> APIproposal
>
> On this topic, I'm not nearly well enough informed on the content.
> However, I question Jessica's reasoning, in that no set of standards
> will help if they aren't followed by all the parties, here IT, AT and
> all the players in between, and violators aren't chastised in some way
> fair and reasonable way.
>
> At it's core, the API proposal is like the standards for our electrical
> power grids. The government regulates how the power source comes out,
> and all the other parties set up their stuff so all the customers can
> get at the power to run their lights. Most of the parties conform
> because the alternative is that people can't safely and cost effectively
> share the power. If anyone in the chain doesn't conform with the
> standard, end users either have dark houses because the light bulbs
> can't get the power, or they have a very bright house while it burns
> down. Either way the government is looking to punish the one who caused
> the problem.
>
> People argued about innovation and standardization when the first power
> grids were set up. Costs, safety and reliability won out over
> unfettered innovation, but it didn't stifle innovation. Folks are still
> inventing better, safer, cheaper ways of delivering power, and they are
> being used to upgrade the power grid. The bottom line then and now is
> that in a society we have to give up a little freedom to make sure we
> all can get at shared resource cheaply, safely and reliable. The
> technology equivalent may be this API or something like it. It is
> needed so all of us can share, and conformance by all is essential for
> it to work.
>
> If this API proposal isn't perfect in some ways, what would make it
> better so everyone would want to follow it? And then, what type of
> enforcement system is needed so the non-likeminded in society get
> brought into line?
>
> Barbara Lybarger
>
> -----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