BAF: if we continue to use this standard as a base, we need to 
clarify the application of priorities.  We also need to contrast it 
to other common standards that may apply (especially US section 508) 
as many tool vendors desire to conform to these standards as well. 
 Certainly we don't want to have conflicting rules (one standard 
requires something another explicitly disallows). Again this is a 
reason to revisit the delegation to ISO.  Note that this is an early 
assessment and may be revised or extended (i.e., more issues found).

ISO 9241 Part 171 has two priority levels - Required and Recommended. 
It also specifies, for each requirement, whether it is an application 
only requirement, an OS only requirement, or both an application and 
OS requirement. IBM is concerned mostly with the application 
requirements but we also looked at the OS only requirements for their 
impact to IBM operating systems.


Application only:

8.15 Enable user control of time-sensitive information: 508 
1194.21(h) requires that information presented in an animation also 
be available in a non-animated form. This ISO item requires that 
software provide a way to stop or pause moving, blinking, scrolling 
or auto-updating information.
10.2.1.4 Enable individualization of user interface elements: As 
worded, apps would have to provide a mechanism enabling users to 
individualize the interface look and feel including the modification 
or removal of command buttons.
12.1 through 12.7: These are requirements on multi-modal interfaces. 
There is not enough information provided to understand the 
requirements. we cannot assess the impact of these requirements until 
we have more information.

Both application and OS:

8.1.2 Use the OS accessibility services: This would disallow any 
accessible Java applications since the Java AAPI is not an OS 
accessibility service.
8.2.1 Enable user input/output choice: This is the fundamental 
accessibility principle. All of the requirements in 508, CI 162, and 
even this proposed ISO standard are specific techniques for providing 
this function. This is too broad to be an additional conformance 
requirement and it should be removed.
8.3 Enable full use via keyboard: 508 essentially excludes drawing 
applications. ISO does not.
8.11 Enable persistent activation: This was the lowest priority in 
the previous draft but has been raised to the highest priority in 
this draft. This would require tear-off menus and "settings" dialogs 
that remain open (as in Lotus apps vs. MS Office apps)
10.1.3.2 Provide keyboard input from all standard input mechanisms: 
If OS provides, app doesn't have to. But if OS doesn't provide an 
onscreen keyboard to allow mouse input of keystrokes, for example, 
app would have to provide it. This should be changed to an OS only 
requirement.
10.1.3.5 Enable the re-assignment of (mouse) button functions, 
10.1.3.8 Provide individualization of delay of pointer-button-press 
acceptance & 10.1.3.12 Provide individualization of pointer movement 
acceleration adjustment: The way these are worded, apps would have to 
provide these mouse customization functions if the OS doesn't. Should 
either be OS only requirement or explanation reworded to clarify that 
apps only have to support if OS provides the service.
10.2.1.3 Enable individualization of cursor and pointer: Should be OS 
only requirement. Apps should only be required to support if OS 
provides the service.
11.1.4.1 Enable font individualization and legibility: 1194.21(g) 
support user display settings. If OS doesn't support, no requirement 
in 508 for app to provide. 1194.31(b) requires a mode of operation 
that does not require visual acuity greater than 20/70 or support for 
assistive technology used by people with visual impairments. ISO 
9241-171 requires apps to provide this function even if the OS 
doesn't.
11.1.5.6 Provide contrast between foreground and background: Requires 
software to choose foreground and background colours (hue and 
luminance) that provide contrast regardless of color perception 
abilities.
11.1.6.7 Synchronize speech output: Requires speech to appear 
immediately after the event that triggered it. This is a bad 
requirement. The events don't originate the speech output. The events 
are passed to the AT. The AT then decides what to do. It may or may 
not invoke speech output via the OS speech APIs. But it cannot be a 
requirement on the OS or the application because it's completely out 
of their control.
11.2.2.1 Provide understandable documentation: This is not measurable.

OS only:

8.1.1 Enable communication between software and assistive technology: 
Impacts i-series and z-series unless we can satisfy this requirement 
through emulation on an OS that supports this requirement. x-series 
(AIX) will not support until Gnome API is golden.
8.4 Accept the installation of keyboard and/or mouse emulators: 
Impacts x-, i-, and z-series.
8.17 Provide accessible system start-up and restart: Impacts x-, i-, 
and z-series
8.18 Enable software-controlled media extraction: Impacts x-, i-, and z-series
10.1.1.5 Provide individualization of delay before key acceptance 
(Slow Keys): Impacts x-, i-, and z-series
10.1.3.18 Provide pointer control of keyboard functions: This is a 
duplicate of 10.1.3.2 and should be removed.
10.1.4.1 Be speech recognition friendly: Impacts x-, i-, and 
z-series. Requires OS to provide speech reco APIs.
11.1.6.6 Provide speech output services: Impacts x-, i-, and 
z-series. Requires OS to provide TTS APIs. Mentions Java speech API 
as an example which is interesting since Java is not part of the OS.


Application only:

11.1.1.1 Start, stop, pause and replay media : Only affects "player" software
11.1.1.2 Allow user to control presentation of multiple media steams: 
requires user to be able to turn off audio and view captions only. 
Supporting the system setting to mute the sound should be sufficient 
to meet this requirement but this is not explicitly stated.
11.1.6.8 Use tone pattern rather than tone value to convey 
information: Only applicable to software that generates tones. 
Requirement is to use temporal or frequency-based tone patterns 
rather than using a single absolute pitch or volume.
11.1.6.9.1 Display any captions provided: "Player SW" only. Must have 
ability to display captions.
11.1.6.9.3 Support system settings for captioning: Example would 
require an application to display captions if ShowSounds is enabled.

Both application and OS:

9.6 Allow assistive technology to access resources: Only required if 
the OS provides the service. Must allow the AT to get the resources 
it needs to run. We used to have this in the Java checklist.
9.7 Present user notification using consistent presentation 
techniques: Example is displaying status messages in a consistent 
status area of the window and error messages in a message box. This 
requirement is not addressed by 508 but we expect that this is not an 
issue for most IBM software.
10.1.1.3 Enable generation of keyboard input: Says you have to be 
able to generate keyboard input from other input devices or SW. We 
think this is the job of the OS standard input APIs and apps are 
required to use standard input per 9.1.
11.2.1.1 Allow task-relevant warning or error information to persist: 
CI 162 allows this as one method of meeting the timed response 
checkpoint.

OS only:

10.1.1.4 Enable sequential entry of multiple keystrokes (Sticky 
Keys): 508 1194.21(b) requires only that software not interfere with 
accessibility features of the OS. There is no requirement for the OS 
to provide them. This is an issue for IBM operating systems (i-series 
and z-series) but we don't think they use multiple keystroke entry. 
ACTION: confirm this.
10.1.1.10 Provide parallel keyboard control of pointer functions 
(Mouse Keys): 1194.21(b) requires only that software not interfere 
with accessibility features of the OS. There is no requirement for 
the OS to provide them. This is an issue for IBM operating systems 
(i-series and z-series) but we don't think they use mouse input at 
all. ACTION: confirm this.
10.1.3.14 Finding mouse pointer: Could impact i-series and z-series 
but they don't support mouse input at all.
11.1.2.4 Provide access to information displayed in "virtual" screen 
regions (OS only requirement): Requires scrollable dialog boxes so 
that if the text size is enlarged to the point where the dialog box 
won't fit on the screen, the user can scroll to see the virtual 
screen areas. Impacts i-series, x-series, and z-series.
11.1.3.3 Enable "always on top" windows (OS only requirement): 
Impacts x-series, i-series, and z-series.

Not specified:

10.1.3.3 Direct external control of mouse position: There is no 
specification whether this requirement is for OS only, application 
only, or both. The explanation talks about the mouse driver so we 
suspect this will be an OS only requirement. If so, it might impact 
i-series and z-series but they don't support mouse input at all.
10.1.3.15 Enable pointer individualization: There is no specification 
whether this is for OS only, application only, or both. This should 
either be OS only or apps should only be required to support it if 
the OS provides the service.


Application only:

9.1 Use system standard input/output: 508 addresses this only for 
output of text in 1194.21(f). Standard keyboard input is implied by 
1194.21(a) but not specifically stated. Only a problem for apps that 
do not use standard mouse and keyboard inputs.
11.1.1.3 Update equivalent alternatives for dynamic content when the 
dynamic content changes (application only requirement): Requires 
captions and audio descriptions to be kept current with content. Not 
specifically addressed by Section 508 but if the equivalent 
alternatives don't match the dynamic content, they are not equivalent 
so we believe this is implied.

Both application and OS:

9.3 Make event notification available to assistive technologies & 9.5 
Allow assistive technology to change the focus and selection 
attributes: This is only required to be supported by apps if the OS 
provides the service. 508 doesn't have this specific requirement 
however 1194.21(l) requires forms to be accessible. We don't believe 
forms could be made accessible without meeting these requirements. As 
long as apps use the system event APIs, this should not be an issue.
10.1.1.16 Separate keyboard navigation and activation: Not specified 
by 508 but 1194.21(a) Keyboard operation is not really possible 
unless you have this. Should add to required techniques in SW 
checklist.