Thread Subject: Re: 1194.22(b) in Group A: Re: JimTobias' commentabout requiring AT

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: Peter Korn
Date: Fri, Oct 20 2006 12:50 AM

Hi Jim,

[sorry for something of a top-post; I want to reply to multiple of your
comments all at once]

Perhaps I read more into your statement than was there. I did initially
presume a suggestion of more sophisticated "accessibility features" like
a screen reader. Also, the word "require" was a flag for me.

I believe we should strive to satisfy multiple,
not-necessarily-conflicting, goals:
1. Preserve maximum flexibility and opportunity for innovation in
addressing accessibility needs
2. Provide maximum clarity and measurability in the standards, to avoid
ambiguity and aid in the application of these standards by adopters and
implementors

So I think it makes sense to enumerate in some way the known best
practices and techniques in detail, while not requiring that those
techniques be the only way of realizing the outcome. As I noted in my
reply to Tamas, the language in 1194.5 may be sufficiently strong that
we can be prescriptive in 1194.21. I just want to be clear that any
other technique that achieves the accessibility outcome should be
acceptable.

You ask this specific question:
> Assuming the equivalent facilitation language, would you
> support language that says "the operating system must allow a user to
> operate all keyboard functions with a single keypress"? If not, why not?
>

I think your quoted language is essentially a specific example of the
general case stated in the existing 1194.31(f): "At least one mode of
operation and information retrieval that does not require fine motor
control or simultaneous actions and that is operable with limited reach
and strength shall be provided." Perhaps that specific example, among
others, should be enumerated somewhere, with a "cf. StickyKeys,
FilterKeys, BounceKeys" as a documented best practice. I'm not at all
against a statement generally along these lines.

But as you note elsewhere, this language brings up an issue I think we
need to discuss and illuminate more: what constitutes an "operating system".

1194.21 is "Software applications and operating systems", but most of it
is really about applications and about user interface frameworks (e.g.
the graphical toolkit like that in Win32 or in Java Swing) that are used
by applications to rendering graphical user interfaces. For example,
1194.21(c) isn't an OS function. Neither is 1194.21(a). Industry has
addressed 1194.21(d) through the development of accessibility
programming interfaces (or programming contracts) implemented by GUI
toolkits -> MSAA for Win32, the Apple Accessibility API on Carbon and
Cocoa, JAA for Java, and the GNOME Accessibility API in UNIX as
implemented by GTK+, UNO, XUL, and bridged from Java. Their adoption by
apps and AT is happening because they have become standard on their
respective operating systems/platforms. And a large number of
applications use 1194.21(d) to accomplish via equivalent facilitation
the specific technique prescribed in 1194.21(f) [things like Java
applications that use Java2D to decode and render Postscript fonts
directly; also things like X servers running on Windows that do their
own font rendering].


Clearly software applications and assistive technologies live on an
operating system, or at least on a "platform". And I feel that the
operating system/platform has a definite role to play in providing
accessibility. In any given OS, how the responsibilities are divided
amongst OS, app, and AT may differ (though again, we can have a best
practice that we reference/suggest).

For example, in the Java Standard Edition platform running on Windows or
Macintosh or UNIX, we don't need to provide something like StickyKeys
functionality because the "host OS" provides it; we simply need to not
break it. On the other hand, we do need to convey to Java applications
the desktop theme settings so that applications can recognize them,
respect them, and behave accordingly. In fact we do more than that -
for users of the Swing user interface toolkit who choose the default to
have their visual look match that of the desktop, we automatically
change that visual look so that it matches the desktop theme (which is
our interpretation of 1194.21(g)).


Let's look at another example: PDAs and cell phones are increasingly
running rich operating systems. Many are running Linux. Some have rich
GUIs (cf. the Nokia 770 Internet Tablet). Should 508 say that such a
device *must* have StickyKeys in order to be purchased under 508 (or at
least, must it have StickyKeys if it has a keyboard with modifier
keys)? What if instead the vendor offered a keyboard at the same price
as the standard keyboard that did the key latching itself? That feature
wouldn't be an "OS feature" at all; that is a hardware solution that
accomplishes the stated end user goal. What if all apps running on one
of these devices used a GUI toolkit that provided StickyKeys like
functionality?

You also ask:

> What is so special about OSs versus application software or websites? How
> could it be "wrong" to require OSs, but not apps and sites, to have certain
> accessibility features?

There are some subtle differences which may be relevant. Apps run on a
platform (generally an OS). While there are multi-platform apps, they
are either running inside some sort of virtual machine (e.g. the Java
runtime environment), or they have some amount of platform-dependent
code that manages the OS-specific parts [putting the menu bar at the top
of the screen on Macintosh, vs. at the top of the window on Windows].
By contrast, web documents, like many documents, have to run on some of
the widest ranges of places. And many web documents and other documents
don't themselves contain code - though some are driven by code (e.g. a
program on a server serving up pages). Those that do contain actual
code - Javascript, Flash, Java applets, AJAX - are I think more properly
seen as applications.

In any case, I think for any given "platform", one can reasonably draw a
line separating accessibility responsibility between the OS and the apps
on that OS. I think today we find that Window, Macintosh, and graphical
UNIX are all moving to draw that line in the same basic place: with the
OS providing a significant number of services to support accessibility
on the platform overall [including the StickyKeys family of tools, some
AT, an accessibility API/framework for app+AT communication]. But is
this the right place for things to converge on a phone with an OS that
runs apps? Maybe. But maybe not.

In contrast, with something like a static document, all the information
that is needed for accessibility must be contained within that document,
or referenced from that document, or otherwise available to the app
within which the document is being used. When the document becomes an
application - an AJAX based web-app for example - then I think we need
to shift to the application rules, but with the additional twist that
the app player becomes a "platform within a platform", and perhaps has
some additional, special responsibilities.


I hope I've managed to answer your questions, and not simply muddy the
waters further...


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


>> -----Original Message-----
>> From: Peter Korn [mailto: = EMAIL ADDRESS REMOVED = ]
>> Sent: Thursday, October 19, 2006 1:53 PM
>> To: TEITAC Web/Software Subcommittee
>> Subject: [teitac-websoftware] 1194.22(b) in Group A: Re: Jim
>> Tobias' commentabout requiring AT
>>
>> Jim's comment on 1194.22(b) is:
>>
>> 'Jim Tobias: Going beyond this provision, how about requiring
>> operating systems to include certain accessibility features?
>> The major operating systems do have such features. The list
>> of required features would have to be decided upon, and even
>> more difficult, an agreement as to what constitutes an
>> "operating system".'
>>
>> I am a bit concerned with this. While I'm delighted to see
>> what appears to be actual competition among OS vendors in
>> bundling AT with their OSes (as we now have competition in
>> car manufacturers as to how may air bags they have), I do not
>> think we should require that. I think it is wrong to place a
>> barrier to entry in the OS market saying that you have to
>> provide specific AT with your OS, or specific "accessibility
>> features".
>>
>
> What is so special about OSs versus application software or websites? How
> could it be "wrong" to require OSs, but not apps and sites, to have certain
> accessibility features? You may have thought I meant screen readers; I
> didn't. I intended us to consider creating a floor for OSs, so that all
> future versions would have to have the same kinds of features they have now,
> like StickyKeys, etc. Otherwise we risk an unlevel playing field indeed.
> Suppose that someone comes up with a really stripped-down OS that can run
> the apps an agency needs, but the OS has no accessibility features. Under
> the current regs, the app complies with the "do not disrupt" provision, but
> since there's nothing in the OS, the user cannot access the app. My
> proposal would eliminate the current lack of accessibility requirements for
> OSs.
>
>
>> I believe we should have outcomes-based requirements (e.g. "a
>> user must be able to operate all keyboard functions with a
>> single keypress"), and then recommend specific guidance as to
>> how to accomplish thing (e.g.
>> "cf. StickyKeys capabilities for latching keyboard
>> modifiers"), and the finally ensure that we don't foreclose
>> innovation (by maintaining 1194.5 Equivalent facilitation
>> "Nothing in this part is intended to prevent the use of
>> designs or technologies as alternatives to those prescribed
>> in this part provided they result in substantially equivalent
>> or greater access to and use of a product for people with
>> disabilities.").
>>
>> I would not explicitly require in 508 that all OSes must
>> include StickyKeys, even though the three most popular
>> desktops (Windows, Mac, UNIX) already do.
>>
>
> I'm not sure I really understand your position. Let me try to rephrase what
> you've written. Assuming the equivalent facilitation language, would you
> support language that says "the operating system must allow a user to
> operate all keyboard functions with a single keypress"? If not, why not?
>
>
>

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