Re: Techiques 1.1 through 1.6

see comment below at MN:

At 6:00 PM 10/12/99, schwer@us.ibm.com wrote:
>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.


MN:  Rich, I think you've confused ShowSounds and SoundSentry, and /or the
description for which you were trying to use.  Please check the appendix of
the techniques doc., and adjust accordingly.





>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 Thursday, 14 October 1999 10:16:17 UTC