Thread Subject: Re: 21 g - revision

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: Gregg Vanderheiden
Date: Wed, Mar 28 2007 9:25 AM

I agree with your comment about 'not interfering with other (unspecified)
products'. We need to put that on our list of "ISSUES TO RESOLVE".


But I also think that we should not include language in our revised
provisions that we do not understand and cannot define. The provision works
fine without the phrase and without any understanding of what it means we
should not promulgate it.

Perhaps "accessibility features documented by the manufacturer" would work.




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



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Andi Snow-Weaver
> Sent: Tuesday, March 27, 2007 3:30 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] 21 g - revision
>
> Gregg,
>
> To your question about what does the phrase "documented
> according to industry standards" used in 21(b) and the
> proposed 21(g) mean?
>
> The only guidance provided currently by the Access Board on
> 21(b) is the
> following:
>
> What is the application programming interface?
>
> The application programming interface, (API) 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 display information on a monitor or
> receive keyboard input via the operating system.
>
> What are accessibility features?
>
> Many commercially available software applications and
> operating systems have features built into the program that
> are labeled as accessibility features. These features can
> typically be turned on or off by a user.
> Examples of these features 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 requirement
> prohibits software programs from disabling these features
> when they have been activated prior to running the application.
>
> <end of AB guidance>
>
> and from the 508 preamble:
>
> 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 text>
>
> So I think this is open to interpretation and I think you
> would find that there are wide variations in how this
> checkpoint is interpreted. As I said before, the subcommittee
> was unable to agree on a better wording for 21(b) so we
> decided to at least make the wording of 21(g) consistent with it.
>
> Frankly, I am more concerned about the requirement to not
> interfere with the accessibility features of "other
> products". A software application runs on some "platform" and
> you can search through the platform documentation to find the
> accessibility features. You could argue whether or not they
> are "documented according to industry standards" but if
> they're documented at all, that's something tangible you can
> use to measure compliance with this requirement. But you can
> never guarantee that you will not interfere with the
> accesssiblity features of "other products" because the set of
> other products is infinitely large. You could never complete
> your testing if you even tried to do this.
>
> Andi
>
>

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