Thread Subject: Re: Possible issues to agree upon

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: James Elekes
Date: Mon, Aug 20 2007 10:05 AM

Hi Phil,

Thanks much for your analysis. As a totally blind
"Screen Reader" User since the first DOS
applications (as well as other AT as well),
you've synthesized the issues I've long heard as
an Access Board Member related to Screen Reader
and their interoperability with Off the Shelf
Software whether it be a Federal employee, State agency or individual.

One comment (not sure it should be part of this
analysis), I currently know of only 1-2 Screen
Reader Programs that with ship with "Contact
Sensitive Help" Files. When the blind Screen
Reader User activates the CTRl/Shft and F1, it
brings a Help Menu up for the particular
application. I've tried/used these menues for
Word and Excel. GW Micro (Window Eyes) is in
process of updating this feature but, in past
conversations, said they have no plans to expand
the offerings to other Software. As you know, the
individual can create their own "CTF" based on
need but, my experience with most other software
is that it's timeconsuming and, you must insure
if creating this "Home Made" version, there is a
logical approach to establishing the "Hot Key"
sequence. I find this is where most who attempt this action fail.

-Jim

James J. Elekes, Chairman
Telecommunications, Electronic/Information Technologies Committee
United States Access Board

(O) 888.564.8430

At 11:31 AM 8/20/2007, you wrote:

>I think there are several issues that we in the
>general sub-committee are discussing around
>Functional Performance Criteria (FPC). How we
>interpret the existing 508 preamble discussion,
>the FAQ, and how we interpret the actual
>provisions in part B can allow us to arrive at
>either different conclusions and/or
>identification of issues (problems with the
>current 508 that TEITAC needs to recommend fixes
>for). I think we need to more clearly document
>the existing issues. Documenting the issue(s)
>can help us make recommendations to the overall TEITAC and Access-Board.
>
>Although it may seem clear to me what the
>access-board intended to say in the preamble
>when it said: "Software that complies with
>§1194.21 would also satisfy this [paragraph a of
>the FPC] provision."; but, that does not remove
>the issue that even when software meets the
>applicable provisions of 1194.21, that an AT may
>need customization to make it work well enough
>for a person who is blind or visually impaired to do their job satisfactorily.
>
>I think we can reach agreement on identifying
>the issue or questions to pose. For
>example, two additional issues we can document are:
>
>1. "Software that is tested with at least one
>screen reader AT shows that it meets the
>provisions of 1194.21, but the screen reader AT
>support has to be customized to improve the
>operating behavior of the software. For example,
>the label and text of a status line in an
>application is directly available to the screen
>reader AT (meets the technical provision), but
>only with custom scripts will any screen reader
>AT automatically announce the text of the status
>line when that text changes or on demand with a
>hot key. Some screen reader ATs are shipped with
>a default configuration that automatically
>handles many versions of some popular
>software. Otherwise, without customization for
>the software, the screen reader AT user would
>have to "look for" the status line (just as the
>sighted user does) and read its text contents to
>understand the software's status. A sighted user
>would do it at a glance, while the screen reader
>AT user would have to customize/configure the
>ability to press a hot key or configure the AT
>to automatically read the status when it changed
>if it wasn't already done by default."
>
>2. "Software that is tested with one screen
>reader AT meets the Functional Performance
>Criteria (FPC) paragraph A, but the software
>does not meet provisions of 1194.21. For
>example, a single screen reader AT support has
>been customized to support most of the product
>functions of the software. During (or prior to)
>the accommodation process a screen reader AT was
>customized to support a specific host (3270
>green screen) application because the label and
>text of an input field in the application was
>not directly available to any screen reader AT
>(failed 1194.21 paragraph L). Only the text and
>color was available to any screen reader AT, not
>the role of the text, not the label, and not
>that the underline characters represented an
>input field. Only with custom scripts will any
>screen reader AT automatically announce the
>input field correctly. Only one screen reader
>AT was customized and tested to prove compliance
>with the FPC. It is assumed, but not proven,
>the it will be possible to customized any other
>screen reader AT for this particular Host (3270 Green Screen) application."
>
>
>Questions:
>
>a. Should the GENERAL subcommittee offer
>guidance or suggestions to TEITAC and
>Access-board regarding each of these issues
>(Yes, I think there is agreement here). Are one
>or both of these cases compliant with 508? Why or why not?
>b. The subcommittee may not agree with any
>single recommendation to give the TEITAC and
>Access-Board, so then we could offer multiple possible recommendations.
>c. Should we offer language that encourages the
>agencies and software vendors to work with AT
>vendors to ship configurations that
>automatically add improved operating behavior
>for software? (Yes, I think there is some
>agreement here but many want more).
>d. Should the language recognize that some
>responsibility for a complete solution still
>rests with the AT vendor, the agency, and end
>user training? (Yes, I think there is general
>agreement here, but we're striving to include as
>much as is practical, testable, allows for
>innovations, and is not anti competitive).
>
>I think it would be helpful to understand any
>actual complaints or reports (Gregg V. and/or
>Terry W.?) that have been received. What is
>the issue? Could they be added to the two I
>identified above? What in the current 508 is
>thought to have lead to the issues? A hole in
>technical provision? What is the proposed solution or change to 508?
>
>I think we have a good start to documenting the
>issues in the GENERAL wiki (see
>http://teitac.org/wiki/General_Interface_Accessibility#Work_Plan).
>We have 1 issues documented about Testability of
>the FPC. The two above might be added and summarized as
>1. primarily - testability. they are good goals but how do you test them?
>2. meets technical provisions, but fails
>current FPC without AT customization/configuration. (see #1 above)
>3. meets the FPC with special AT customization
>but fails the technical provision(s). (see #2 above)
>
>Regards,
>Phill Jenkins
>IBM Research - Human Ability & Accessibility Center
>http://www.ibm.com/able
>

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