W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2000

revised checkpoint 1.5

From: David Poehlman <poehlman@clark.net>
Date: Tue, 18 Jan 2000 17:59:01 -0500
Message-ID: <3884F035.5E90291F@clark.net>
To: Ian Jacobs <ij@w3.org>, User Agent Working group list <w3c-wai-ua@w3.org>, Gregory Rosmeta <unagi69@concentric.net>
As per my action item of Dec 9 1999, taking into account disruption and
disorientation that can occur when a system message event is triggered
and is focused on, after discussion on that day, I've provided the
checkpoint and also some revision to the techniques below.

Please jump in and discuss.

...and Thanks to GR for assisting me with remembering the details...
   1.5 Ensure that all messages to the user (e.g., informational
          messages, warnings, errors, etc.) are available through all
          output device APIs used by the user agent  and that the input
focus does not change when they occur. Do not bypass the
          standard output APIs when rendering information (e.g., for
          reasons of speed, efficiency, etc.) or cause interferance with
an ongoing event such as entering text or choosing configuration
settings. [Priority 1]
          For instance, ensure that information about how much content
          has been viewed is available through output device APIs.
          Proportional navigation bars may provide this information
          graphically, but the information must be available (e.g., as
          text) to users relying on synthesized speech or Braille
output.  A tone or screen flash may alert the user without interrupting
an important task such as typing an email message when a download is
complete or entering parameters into a dialog box when confirmation of
acceptance of acookie is requested.
          Operating system and application frameworks provide standard
          mechanisms for using 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
          the multimedia subsystems.
          It is important to also support standard output notification
          sound such as notifications found in the Windows control panel
          for sounds. Windows maps accessibility features to the event
          caused by generation of these specific system sounds.
          Accessibility features such as SoundSentry will flash the
          screen, as appropriate, in response to events that would cause
          these sounds to play. This enables users with hearing
          disabilities to use the application.

Keeping focus:

an alert that is accompanied by text can be brought into focus in a read
window thus blocking interference with actions and then dismissed or
moved away from.  In the case of a dialog box, the warning indication
could allow for the continuation of action in progress to commence while
suspending any action required by the system message in a timely manner.

Role of A Ts:

A Ts usually bring focus to a new event in ordder that the user of the A
T might gain the information and or be able to take the action that is
called by the event.  A T developpers should work with ua developpers to
develop solutions that work to solve this issue.

          When implementing standard output:
          + Do not render text in the form of a 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
            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).
          + Do not provide your own mechanism for generating pre-defined
            system sounds.
          + When using a device do not use the device driver directly.
            the case of display drivers, 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
            the display driver directly you may be drawing to the
            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.
          + Do not forget to provide a text equivalent to voiced
            messages. Make sure an auditory message also has a redundant
            visual text message. For example, a message like "You've got
            mail" should also be presented with icons or text.
          + Do not preclude text presentation when providing auditory
            tutorials. Tutorials that use speech to guide a user through
            the operation of the user agent should also be available at
            the same time as graphical representations.
Hands-On Technolog(eye)s
voice 301-949-7599
end sig.
Received on Tuesday, 18 January 2000 17:59:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:25 UTC