Thread Subject: dialog on OS-platform-application

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: Jim Tobias
Date: Mon, Oct 23 2006 6:55 AM

> -----Original Message-----
> From: Peter Korn [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Friday, October 20, 2006 2:45 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] 1194.22(b) in Group A: Re:
> JimTobias' commentabout requiring AT
>
<snip>
>
> 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".
>
<snip>
>
> 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.

This is a clear statement of a concept I call the "accessibility value
chain". Like the "value chain" concept from which it is adapted, the
accessibility value chain is a recognition that neither one product nor one
company provides all the functionality required for any particular ICT to be
accessible. Value may be added at several points along the chain, and can
be jeopardized by the presence or absence of specific "links". This concept
is already recognized indirectly in some parts of 508 and 255, and making it
explicit may provide us with a valuable tool for our work.

If we were directly regulating industry, such an approach would seek to
assign clear responsibilities link by link: hardware OSs shalt do thus;
applications shalt do thus, etc. Luckily, we're not regulating industry
directly (in 508 at least). So we can apply a systems approach to the
accessibility value chain. The agency purchasing the ICT can buy whatever
they like as long as one or more accessibility value chains is effectively
in place. To continue with our example, and just as Peter suggests, it
doesn't matter where along the chain "StickyKeys" functionality resides.
>
<snip>
>
> 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.

This convinces me that we need to be prescriptive about the user interface
functionality required within the chain. Although Windows, MacOS, and
graphical UNIX are moving as Peter describes, there's no guarantee that they
will stay the course, or that there won't be other entrants with different
courses. New products and new interface features show up too quickly for us
to rely on a loose, "best practices" approach.

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