Thread Subject: Re: Possible issues to agree upon

From: Peter Korn
Date: Mon, Aug 20 2007 12:10 PM

• Return to this mailing list's archives
• View all messages in this thread
• Next message in thread: None
• Previous message in thread: James Elekes: "Re: Possible issues to agree upon"
• Messages sorted by: Author | Thread | Date

Hi Phill,

I agree that the best and most efficient access for many (most? all?) AT
users comes through application-specific customization on the part of
the AT. In your status bar example below, however, I think we have
techniques that can handle this more generally. In our 3.4-A AT
Interoperability provision, we note that AT must be provided with the
role & state(s) of all user interface elements (among many other
things). In our UNIX Accessibility API we define a "status bar" role,
and the screen reader has general logic about how to deal with windows
containing status bars when the status text/contents updates.

I think is makes sense for us to push the technical provisions as far as
we can, to provide AT with the tools do provide as rich and efficient
and productive access as they can prior to doing any
application-specific customization. App-specific customization takes
time and effort. It is generally done by AT vendors only for the most
popular products in current widespread use.

Phill, you asked a few questions, which I will try to answer in-line below:

> *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?

I think that, so long as the E&IT product makes it clear that the role
of an object is a status bar, it has done what it should and should be
considered compliant with at least that portion of the technical
provisions (your first of two examples). For example #2 with the 3270
terminal application, this application would fail several of the
technical provisions (both 3.4-A, and likely fail the not-yet-finalized
provision(s) around Remote Access systems). However, if the vendor can
demonstrate via the FPC that the purpose if access is met some other way
(e.g. equivalent facilitation via custom scripts written for various AT
products), then such a product ought to be considered compliant. But
note: since the product has failed one or more technical provisions -
and especially because it failed the AT interoperability provision - I
believe the burden of demonstration now falls to the E&IT vendor to show
this works for all disability user scenarios (blindness, low vision,
color vision deficits, limited mobility, etc.). And a real challenge
comes in as we look to the future, as AT improves. For example, to my
knowledge no Windows on-screen keyboard today will extract all of the
text-entry fields and their labels, and create a dynamic keyboard of
them for switch input selection. Thus the failure to provide such
labels to meet 3.4-A won't cause any loss of efficiency or productivity
for a Windows on-screen keyboard user. But the GNOME On-screen keyboard
does offer this functionality, which suggests that E&IT might have a
burden to make that function work there. But this really brings up the
whole challenge of "usability", and how we can even try to measure that.

Fundamentally, what I hope happens is that E&IT discovers that the most
efficient way to meet 508 is to fully meet the technical provisions for
all products, including the AT interoperability provision. This should
serve all of us much better as our solutions evolve and improve.

> 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.

This is a necessary thing TEITAC will have to do in some fashion for
anything it both fails to reach consensus on, and for which individual
members feel so strongly that something must be said.

>
> 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).

I don't think that belongs in 508. I think we can advise agencies to
consider the efficiency and productivity of a task, and whether they
should acquire customized AT behavior for that. But when this is needed
varies tremendously depending upon (a) the frequency a given task is
done, and (b) the potential improvement to be gained by app-specific
custom behavior. For example, the custom scripts that many screen
readers provide for the spell check dialog of a word processor makes a
large difference in efficiency of a task done all the time by anyone
creating a document. On the other hand, a similar script to
automatically read key parts of a dialog seen once during initial
installation of a product will have a negligible impact in that
employee's efficiency and productivity in almost all cases (unless the
employee is employed to do installations of software).

We have talked about having a section that has agency burdens in it (see
5-A "Aggessibility Configuration" for a provision that might be part of
such a section). A recommendation that agencies consider doing this for
AT for certain tasks makes sense (and certainly E&IT products are then
thereby encouraged to highlight to agencies where this work has already
been done). But that is as far as I would go.

> 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).

Yes, of course agencies should recognize this. But what specific
language do you have in mind to support that? 508 is fundamentally all
about what an agency must do in procurement (and with 5-A, some of what
they shall do in deployment). But I don't see what sort of testable
provision such language belongs in.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

>
> 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
> ------------------------------------------------------------------------
>
>

• Next message in Thread: None
• Previous message in Thread: James Elekes: "Re: Possible issues to agree upon"