Thread Subject: dialog on OS-platform-application

Return to this mailing list's archives

From: Jim Tobias
Date: Mon, Oct 23 2006 6:55 AM
Subject: dialog on OS-platform-application

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

From: Gregg Vanderheiden
Date: Mon, Oct 23 2006 10:30 AM
Subject: Re: dialog on OS-platform-application

This topic (who is responsible for what) was addressed in the HFES 200.2
and in parallel in ISO 9241-171. There the term "platform" was used for
software that supported other software. And application was used for end
point software.



See below for specifics



Gregg

-- ------------------------------

Gregg C Vanderheiden Ph.D.




7.1 General




Users of this standard will need to consider all the recommendations that it
contains. In many cases the application of a recommendation may depend on
the particular context of use so that it will be necessary to determine
whether a given piece of guidance is applicable.



This standard is designed to support those responsible for all the aspects
of developing and acquiring software that will be accessible. This will
involve people with different roles and with responsibility for different
aspects of the process. In order to assist the reader in identifying
whether a given clause applies to those parts of the system for which they
have responsibility, a way of categorizing where the guidance needs to be
applied has been developed and is described in Table 1.



Table 1 - Implementation responsibility


Category

Description


Platform software
(the operating system and associated layers, and toolkits)

Operating system, drivers and associated software layers.

Includes Windowing Systems, libraries and associated toolkits that provide
or affect the user interface of other software (e.g. GNOME, KDE, Java
runtime, Visual Basic, applications executing scripts or hosting embedded
objects, etc.)

NOTE: If a software program uses its own routine to override or replace OS
driver functions then the application would need to conform to related
Platform Software provisions.




Application software
(which run on and make use of services provided by platform software)



Software not considered as part of the operating system or its immediate
layers. This includes "desktop" software bundled with an operating system,
personal productivity applications, development tools, Web browsers, and
other non-OS software.


Assistive Technology

Hardware or software that is added to or incorporated within a system that
increases accessibility for an individual. Some portions may function as
platform software while other portions may function as application software
and would be covered above. Guidelines for the design of assistive
technology in general are outside the scope of this document.



Since it is often ambiguous to differentiate between Platform and
Application and since most of the provisions apply to both, we only note
those provisions that would apply to only one or the other.



In order to achieve accessibility it is necessary to provide support in
different parts of the overall software system. While much can be done to
improve accessibility in the design of the application, it is not possible
to provide all of the input and output support that users require in every
circumstance at the application level alone. To the extent that any
particular part of the software is dependent upon a level below it for its
operational characteristics it will be necessary to ensure that the lower
levels enables the implementation of recommended accessibility
characteristics in any layers that depend upon them. This dependency may
occur in relation to different layers in the platform software and in
relation to the applications that are mounted on the platform software.
Applications themselves may have layers that result in dependencies arising
within different levels of the application. The majority of the
recommendations in clauses 8, 9, 10, and 11 require that the issue be
addressed at more than one level of the software system if the particular
recommendation is to be satisfied. In some cases the guidance is related to
either the platform software or applications layers alone. The platform
software is the general means by which accessibility features that involve
control of hardware devices, in particular those involving input, are
implemented and controlled. Some issues that arise in relation to the nature
of the content and the form of its presentation may only apply within the
application layers.



Many recommendations marked are the responsibility of both applications and
portions of the platform software that have or affect a user interface.
Developers of operating systems, toolkits, and other platform components are
encouraged to implement support for these provisions in ways that minimize
the amount of work required by application developers. Application
developers may take advantage of such features where they are available, but
are ultimately responsible for ensuring their products are compatible with
these provisions.