Thread Subject: 1194.21(b) Non-interference with accessibility features of other products

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: Andi Snow-Weaver
Date: Fri, Jun 01 2007 1:00 PM

Peter and Sean are working on rewording of 1194.21(g) but we have similar
problems with 21(b) that we have yet to resolve.

Current wording: Applications shall not disrupt or disable activated
features of other products that are identified as accessibility features,
where those features are developed and documented according to industry
standards. Applications also shall not disrupt or disable activated
features of any operating system that are identified as accessibility
features where the application programming interface for those
accessibility features has been documented by the manufacturer of the
operating system and is available to the product developer.

The issues identified are:

- "other products" is too broad to be testable
- what does "documented according to industry standards" mean?
- "operating system" should probably be "platform software" for consistency
with our other provisions

What kinds of accessibility features and other products do we think the
Access Board was trying to describe with this wording?

<from the preamble>

The application programming interface refers to a standard way for
programs to communicate with each other, including the operating system,
and with input and output devices. For instance, the application
programming interface affects how programs have to display information on a
monitor or receive keyboard input via the operating system. Many
commercially available software applications and operating systems have
features built-into the program that are labeled as access features. These
features can typically be turned on or off by a user. Examples of these
features may include, reversing the color scheme (to assist people with low
vision), showing a visual prompt when an error tone is sounded (to assist
persons who are deaf or hard of hearing), or providing "sticky keys" that
allow a user to press key combinations (such as control-C) sequentially
rather than simultaneously (to assist persons with dexterity disabilities).
This provision prohibits software programs from disabling these features
when selected.

Comment. The proposed rule only specified that software not interfere with
features that affect the usability for persons with disabilities.
Commenters from industry noted that the provision in the NPRM did not
provide any method of identifying what features are considered access
features and further stated that this provision was not achievable. These
commenters pointed out that it was impossible for a software producer to be
aware of all of the features in all software packages that could be
considered an access feature by persons with disabilities. Sun Microsystems
recommended that this provision address access features that have been
developed using standard programming techniques and that have been
documented by the manufacturer.

Response. This provision has been modified in the final rule to reference
access features which have been developed and documented according to
industry standards. No other changes have been made in the final rule.

<end of preamble>

Perhaps if we enumerate some examples of the types of accessibility
features applications should not disrupt or disable, it will help us. The
preamble provides some examples:

- reversing the color scheme - this seems to me to be covered by 21(g)
which Peter and Sean are working on
- showing a visual prompt when an error tone is sounded
- providing "sticky keys"

Others of this type are features to control the mouse from the keyboard
arrow keys (mouse keys), filter out repeated keystrokes (filter keys), and
to provide sounds when locking keys (Caps Lock, Num Lock, etc.) are
pressed.

There is no mention here of more sophisticated AT such as screen readers,
screen magnifiers, onscreen keyboards, etc. Could we conclude that this
provision was only meant to apply to such accessibility features as are
found in the Windows Accessibility Options or AccessX for Unix platforms?
And could the "other products" have been meant to cover platforms that have
such features as add-ons rather than being included in the platform?

For the case where they are included in the platform, I think something
like this would work: "Applications shall not disrupt or disable activated
features of the platform software that are identified as accessibility
features in manufacturer's documentation available to the product
developer."

But how do we describe, in a testable manner, the case where these features
(visual prompts for error tones, sticky keys, mouse keys, etc.) are
available as an add-on? We could enumerate the types of features that exist
today but what if someone comes up with a new one?

Andi

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