Thread Subject: Possible issues to agree upon

Return to this mailing list's archives

From: Phill Jenkins
Date: Mon, Aug 20 2007 9:35 AM
Subject: Possible issues to agree upon

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

From: James Elekes
Date: Mon, Aug 20 2007 10:05 AM
Subject: Re: Possible issues to agree upon

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
>

From: Peter Korn
Date: Mon, Aug 20 2007 12:10 PM
Subject: Re: Possible issues to agree upon

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