Achieving Greater Accessibility for Blind User of OS/2
By Catherine K. Laws February 3, 1995 Author contact: Catherine K. Laws Author phone: (407)982-3918 FAX: (407)982-6059 IBM Internal E-mail: BCRVM1(LAWS) Internet ID: email@example.com
Address: Special Needs Systems Development IBM Corporation P.O. Box 1328, Internal Zip 5432 Boca Raton, Fla. 33429
“Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation”
Try to imagine using OS/2(*) or Windows(* *) on your system with the display turned off. What information would you need? What windows are open? What programs are running? What is the foreground window? What is the program name and title? What type of control is currently selected and what is the text associated with that control? Thousands of computer users who are blind or visually-impaired are faced with these questions each day. Screen reader products can help them answer these questions.
A screen reader product is a computer-access system that enables blind and visually-impaired people to use OS/2, Windows, and/or DOS applications. Prior to graphical user interfaces (GUIs) such as OS/2 Presentation Manager(*) (PM) and Microsoft Windows, screen reader products for DOS had little difficulty accessing the text-based information displayed on computer screens. The advent of GUIs has significantly complicated the ways in which any screen reader can access screen information.
Are there things that you, the GUI application developer can do to make your product more easily accessible? Absolutely! This article explains how the IBM Screen Reader/2(*) product accesses text and graphical screen information. Then programming techniques are suggested to help you achieve greater Screen Reader/2 accessibility for your application. Hints for developing your applications are in italics.
- 1 1.1 INTRODUCTION TO SCREEN READER/2
- 2 1.2 TEXT-BASED SCREEN ACCESS
- 3 1.3 ACCESS TO THE GRAPHICAL USER INTERFACE
- 4 SUMMARY
- 5 REFERENCES
1.1 INTRODUCTION TO SCREEN READER/2
A Screen Reader/2 system consists of the following components:
- IBM Personal Systems-compatible computer
- Operating System/2 Version 2.1 or later
- Software and documentation
- Screen Reader keypad connected to a mouse port or Screen Reader adapter
- Text-to-speech synthesizer connected to a serial port
As you open and close windows and move the cursor or mouse pointer in both OS/2 and Windows applications, Screen Reader/2 automatically speaks, through the synthesizer, the window title, selected items, and other system information.
To get information that is not spoken automatically, you use the Screen Reader/2 keypad. Arranged like a United States telephone keypad, the eighteen keypad keys are: 0-9, A, B, C, D, *, #, Stop, and Help. Each key, or combination of keys, performs a specific screen-reading function.
Keypad functions and procedures for automatically speaking screen information are defined in profiles. Profiles are developed for PM, Windows, and DOS applications using Screen Reader/2's Profile Access Language (PAL).
When Screen Reader/2 starts, a base profile is activated. The base profile handles all basic keypad key sequences and information spoken automatically for standard Presentation Manager (PM) and Windows controls. When an application starts, an additional application-specific profile may be activated to handle key sequences and information spoken for unique features of an application. Application-specific profiles are not required to make an application accessible, but they often provide easier access to an application's screen information.
1.2 TEXT-BASED SCREEN ACCESS
All the displayed information (color, characters, cursor) for text-based OS/2 (non-PM) and DOS applications is available to screen readers. A Screen Reader/2 user of text-based applications can find out everything the sighted user sees using the base profile keypad key sequences. In addition, a user can write an application-specific profile to provide screen information to the user automatically and using fewer keypad key sequences.
1.3 ACCESS TO THE GRAPHICAL USER INTERFACE
With the graphical user interface (GUI), a screen reader does not have immediate access to text and icons displayed on the GUI screen because everything is just pixels. To gather as much screen information as possible, Screen Reader/2 intercepts display driver calls before the text and icons become pixels. Using the intercepted information and additional data obtained through graphics engine and Presentation Manager API calls, Screen Reader/2 constructs an off-screen model (OSM) database. This database describes the text, bitmaps, icons, and cursors on the screen and their positions, sizes, window handles, and other information. As window focus changes and the cursor and mouse pointer moves, PM and Windows profiles direct Screen Reader/2 to tell the user what is happening using information obtained directly from PM APIs, from standard operating system hooks, and from the off-screen model of the display.
1.3.1 GUI TEXT
A screen reader recognizes text more easily than anything else on the display. Screen Reader/2 captures text before it is converted into and displayed as part of the graphical user interface. Text is saved in the off-screen model together with its window handle, position, color, font, and style.
USE INFORMATIONAL, STATIC TEXT TO IDENTIFY EXPECTED INPUT AND CONTROLS. Position static text for a control immediately above or to the left of your control. To avoid reporting erroneous information, Screen Reader/2 speaks only static text which is carefully positioned in this way.
GROUP SETS OF CONTROLS USING GROUP BOXES. Give each group box carefully chosen text. Screen Reader/2 automatically announces the static text of a group box so the user knows more about the current control selected and that related controls exist.
An entry field and arrow buttons with text to the right are not announced together by Screen Reader/2.
An entry field and arrow buttons in a group box are announced together by Screen Reader/2.
1.3.2 ICONS AND BITMAPS
A BITMAP is a representation in memory of data displayed on the screen. An ICON is a pictorial representation of an item, such as a data object, system action, or minimized program, that a user can select. Screen Reader/2 cannot be certain whether a bitmap sent to the display with a BitBlt operation is intended to be an icon or a simple picture. Since we found the size of most icons to be 40 by 40 pels or smaller, Screen Reader/2 recognizes any bitmap of this size as an icon.
To recognize icon bitmaps, Screen Reader/2 calculates a checksum for the bitmap and associates the checksum with the bitmap handle. The checksum is referred to as an icon code. To identify icons to the blind user, display-dependent, resolution-dependent tables of icon codes associated with text are used. A user can add new icon codes to these icon tables.
If your application displays a selectable icon without text, then a user must add an icon code and some descriptive text to the icon tables. To do this, the user may need sighted assistance. Even a sighted user may not understand the purpose of a particular icon.
PROVIDE TEXT-BASED ALTERNATIVES FOR SELECTABLE ICONS. If your application has a menu bar or set of icons from which the sighted user can choose, then also provide a corresponding text-based menu either combined with the icons or separately. For example, every OS/2 2.1 folder is a collection of icons together with text.
An icon-based menu with no associated text is not accessible without sighted assistance.
A text-based alternative can be provided through an option in a settings notebook.
1.3.3 WINDOWS AND THE SCREEN READER/2 VIEW
Most of the time we think of an OS/2 window as a frame window, complete with a title bar, a client area, and other optional elements such as a system menu icon and minimize and maximize icons. The client area usually contains the main information of the window, such as text, group boxes, pushbuttons, entry fields, and other controls.
A VIEW is a rectangular area of the screen within which Screen Reader/2 confines its reading. Except for notebooks, the view is determined by a frame window and all its children. Whenever a focus change occurs, the Screen Reader/2 view is recalculated based on the frame window containing the focus window.
USE FRAME WINDOWS AS INTENDED, TO DEFINE YOUR "MAIN" WINDOW. If an application creates a frame window that contains only a pushbutton, for example, then the Screen Reader/2 view may contain only the pushbutton and the blind user will lose application accessibility.
1.3.4 CURSORS, SELECTED ITEMS, AND FOCUS
The worst nightmare for any screen reader is losing sight of the current "active point." The user must know where on the screen keyboard input is directed and what effect the input will have. Without this information the application is unusable.
In text mode, the symbol displayed on the screen showing where text will be placed is called the cursor. For text-mode applications, Screen Reader/2 finds the cursor position in a data structure associated with a logical video buffer.
The corresponding cursor object in the graphical user interface is often known as an insertion bar. Screen Reader/2 has difficulty recognizing a cursor for a GUI application because it must somehow determine that some
graphical object, such as a line, a box, or an inverted character, is a cursor.
Screen Reader/2 recognition of selected items is similar for both text mode and GUIs. Selected items can be color reversed, shaded, or fitted inside a box. A box can be drawn using many different kinds of graphical APIs.
USE THE STANDARD PM AND WINDOWS CURSORS instead of creating your own cursor. If an application creates its own cursor, then Screen Reader/2 probably cannot find it. A blind person cannot use this type of application.
ALWAYS GIVE FOCUS TO THE WINDOW RECEIVING INPUT. To provide information to a blind user, Screen Reader/2 must always be able to find the input focus window. For example, in one application we found a window that has a standard cursor and seems to accept input but that window does not have the focus. Applications with this kind of focus problem are unusable for Screen Reader/2 users.
To get state information for standard window items or controls, such as whether a box is checked or not, Screen Reader/2 sends a message to the control window. Screen Reader/2 cannot obtain state information for a control class which is not listed as one of the predefined classes documented in the toolkit books for PM and Windows.
USE THE PREDEFINED CLASSES OF CONTROLS DEFINED IN THE PM AND WINDOWS TOOLKIT BOOKS. Avoid creating your own controls if you can use or subclass predefined PM and Windows controls. The predefined control classes for OS/2 Version 2.1 PM are:
WC_BUTTON WC_COMBOBOX WC_CONTAINER WC_ENTRYFIELD WC_FRAME WC_LISTBOX WC_MENU WC_MLE WC_NOTEBOOK WC_SCROLLBAR WC_SLIDER WC_SPINBUTTON WC_STATIC WC_TITLEBAR WC_VALUESET
The predefined control classes for the Windows 3.1 environment are:
EDIT LISTBOX MIDICLIENT SCROLLBAR STATIC
Screen Reader/2 automatically recognizes and can obtain state information about predefined PM controls except the WC_SLIDER and the WC_VALUESET controls. The same is true for predefined Windows controls except the SCROLLBAR controls. Screen Reader/2 code can be updated to tell its users about these predefined controls because all the information about them is documented in the PM toolkit books.
IF YOU SUBCLASS A PREDEFINED CONTROL CLASS, USE THE SAME CLASS NAME SO THAT A SCREEN READER WILL RECOGNIZE THE CLASS AND BE ABLE TO GET STATE INFORMATION.
If you define your own controls, a screen reader will not be able to automatically identify the class name and other information about the control for a user without modification to the screen reader code. Screen Reader/2 does have some unique code to handle a few user-defined controls in some popular applications. However, changing screen reader code to handle all current and future user-defined controls would be very difficult!
Some user-defined menu controls do not behave like any of the predefined controls. These menus never have the input focus, so Screen Reader/2 never recognizes a selection cursor for these menus. WHENEVER POSSIBLE, USE PREDEFINED MENU CONTROLS AND GIVE FOCUS TO A MENU ITEM WHEN IT IS SELECTED.
1.3.6 KEYBOARD ACCESS
In general, blind users must use keyboard keys rather than a mouse. Keyboard keys are usually documented as part of a menu item or help information. Screen Reader/2 automatically speaks accelerator keys associated with menu items.
ASSIGN KEYBOARD KEYS TO ACCESS ALL OF YOUR APPLICATION'S FUNCTIONS. Avoid creating functions that are accessed by using only a mouse. Remember to document all keyboard usage, including keyboard alternatives to mouse actions, in help panels and as part of your menu items.
Graphical user interfaces have created new accessibility challenges for blind users and screen-reader systems. As a GUI application developer, you can make your product more accessible for all users, especially blind screen reader users, by using the following programming techniques:
- Provide text-based and keyboard-based alternative ways to use your application.
- Use standard cursors and predefined control classes as much as possible.
- OS/2 2.0 Presentation Manager Programming Reference Volume III (IBM Doc. S10G-6272-00)
- Microsoft Windows Version 3.1 Programmer's Reference Volume 2: Functions. Microsoft Corporation, 1987-1992. (Document No. PC28916-0492)
(*) Trademark of the IBM Corporation (* *) Trademark of the Microsoft Corporation