Techiques 1.1 through 1.6

Ian,

The following are techniques 1.1 through 1.6 as transcribed at the User Agent
Working group meeting:

Technique 1.1

Operating system and application frameworks provide standard mechanisms for
providing navigation control to your application for standard input devices. In
the case of Windows, OS/2, the X Windows System, and MacOS,GUI applications are
provided this information through the messaging queue through the window
manager. In the case of non-GUI applications, the compiler run time libraries
provide standard mechanisms for recieving keyboard input in the case of desktop
operating systems. Should you use an application framework such as the Microsoft
Foundation Classes, the framework used must support the same standard input
mechanisms.

When implementing custom GUI controls do so using the standard input mechanisms
defined above. Examples of not supporting the standard input devices are:

- Do not communicate directly with the device such as directly opening the
keyboard device driver in Windows. This may result in sytem messaging
circumvention. It is often the case that the windowing system needs to change
the form and method for processing standard input mechanisms for proper
application coexistence within the user interface framework.

- Do not implement your own input queue handler. Devices for mobility access,
such as those that support serial
keys, use the standard input queue to control applications.

Technique 1.2

When providing input control to document elements in your user agent ensure that
you follow the techniques defined in technique section 1.1. Any output resulting
from user actions should use the techniques defined in technique 1.6.

Technique 1.3

When creating or using installation software ensure that it is navigable using
the techniques 1.1 and 1.6. Installation
software includes normal program update mechanisms included during normal
program operation.

Technique 1.4

When creating the user agent software, including installation and
deinstallation, ensure that it can be configured
using techniques 1.1 and 1.6.

Technique 1.5

Ensure that the user can access user agent documentation using the User Agent
Accessibility Guidelines. A way to do this in Windows would be to create help
files in HTML so that you can use a Windows browser designed to meet the User
Agent Accessibility Guidelines. This HTML source would also need to follow the
Web Content Accessibility Guidelines.

Technique 1.6

Operating system and application frameworks provide standard mechanisms for the
use of standard output devices. In the case of common desktop operating systems,
such as Windows, OS/2, and MacOS standard API are provided for writing to the
display and the multimedia subsystems.

It is important to also support standard output notification of sound such as
those found in the Windows control panel for sounds. Windows maps accessibility
features to respond to the event caused by generation of these specific system
sounds. Accessibility features such as show sounds would flash the screen, as
appropriate, in response to events that would cause these sounds to play. This
enables the deaf user to user your application in the absence of sound.

When implementing standard output you would not want to:

- Render text in the form of bitmap before transferring to the screen. Screen
Readers intercept text drawing calls to create a text representation of the
screen, called an offscreen model, which is read to the user. Common operating
system 2D graphics engines and drawing libraries provide functions for drawing
text to the screen. Examples of this are the Graphics Device Interface (GDI) for
Windows, Graphics Programming Interface (GPI) for OS/2, and for the X Windows
System or Motif it is the X library (XLIB).

- Provide your own mechanism for generating pre-defined system sounds.

- When using a device do not use the device driver directly. Screen readers are
designed to monitor what is drawn on the screen by hooking drawing calls at
different points in the of the drawing process. By calling the display driver
directly you may be drawing to the display below the point at which a screen
reader for the blind
is intercepting the drawing call.

- Do not draw directly to the video frame buffer. This circumvents the
interception point at which a screen reader hooks the display calls.


Rich Schwerdtfeger
Lead Architect, IBM Special Needs Systems
EMail/web: schwer@us.ibm.com http://www.austin.ibm.com/sns/rich.htm

"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the difference.", Frost

Received on Tuesday, 12 October 1999 19:02:45 UTC