Achieving Greater Accessibility for Blind User of OS/2: Difference between revisions

From OS2World.Com Wiki
Jump to navigation Jump to search
Created page with " 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 ..."
 
Jugbogdan (talk | contribs)
mNo edit summary
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
By [[Catherine K. Laws]]
''By [[Catherine K. Laws]]'' - February 3, 1995
February 3, 1995
   
   
Author contact: Catherine K. Laws
:Author contact: Catherine K. Laws
Author phone: (407)982-3918
:Author phone: (407)982-3918
FAX: (407)982-6059
:FAX: (407)982-6059
IBM Internal E-mail: BCRVM1(LAWS)
:IBM Internal E-mail: BCRVM1(LAWS)
Internet ID: claws@vnet.ibm.com
:Internet ID: claws@vnet.ibm.com


Address:
Address:
Special Needs Systems Development
:Special Needs Systems Development
IBM Corporation
:[[IBM]] Corporation
P.O. Box 1328, Internal Zip 5432
:P.O. Box 1328, Internal Zip 5432
Boca Raton, Fla. 33429
:Boca Raton, Fla. 33429


'''“Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation”'''
{{IBM-Reprint}}


Try to imagine using OS/2(*) or Windows(* *) on your system
Try to imagine using OS/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.
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
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.
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
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/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.
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 INTRODUCTION TO SCREEN READER/2==
==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.


A Screen Reader/2 system consists of the following
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.
components:


    IBM Personal Systems-compatible computer
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).
    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
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.
pointer in both OS/2 and Windows applications, Screen


==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.


(*) Trademark of the IBM Corporation
==1.3 Access tp 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.


(* *) Trademark of the Microsoft Corporation
===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.


Reader/2 automatically speaks, through the synthesizer, the
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.
window title, selected items, and other system information.


To get information that is not spoken automatically, you use
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.
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
An entry field and arrow buttons with text to the right are not announced together by Screen Reader/2.
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.
An entry field and arrow buttons in a group box are announced together by Screen Reader/2.
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==
===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.


All the displayed information (color, characters, cursor)
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.
for text-based OS/2 (non-PM) and DOS applications is
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.
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==
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.


With the graphical user interface (GUI), a screen reader
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.
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===
An icon-based menu with no associated text is not accessible without sighted assistance.


A screen reader recognizes text more easily than anything
A text-based alternative can be provided through an option in a settings notebook.
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
===1.3.3 Windows and the Screen Reader/2 View===
AND CONTROLS. Position static text for a control
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.
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
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.
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.
USE FRAME WINDOWS AS INTENDED, TO DEFINE YOUR "MAIN" WINDOW.
If an application creates a frame window that contains only
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.
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===
===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.


The worst nightmare for any screen reader is losing sight of
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 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
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.
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
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.
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
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.
character, is a cursor.


Screen Reader/2 recognition of selected items is similar for
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.
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
===1.3.5 CONTROLS===
your own cursor.  If an application creates its own cursor,
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.
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.
 
===1.3.5 CONTROLS===
 
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:


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_BUTTON
     WC_COMBOBOX
     WC_COMBOBOX
Line 278: Line 108:
     WC_TITLEBAR
     WC_TITLEBAR
     WC_VALUESET
     WC_VALUESET
 
The predefined control classes for the Windows 3.1 environment are:
The predefined control classes for the Windows 3.1
environment are:
 
     BUTTON
     BUTTON
     COMBOBOX
     COMBOBOX
Line 290: Line 117:
     SCROLLBAR
     SCROLLBAR
     STATIC
     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.


Screen Reader/2 automatically recognizes and can obtain
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.
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
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!
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
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.
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.


==SUMMARY==
===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.


Graphical user interfaces have created new accessibility
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.
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:


==Summary==
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.
* Provide text-based and keyboard-based alternative ways to use your application.
* Use standard cursors and predefined control classes as much as possible.
* Use standard cursors and predefined control classes as much as possible.


 
==References==
==REFERENCES==
 
* OS/2 2.0 Presentation Manager Programming Reference Volume III (IBM Doc. S10G-6272-00)
* 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)


* 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


[[Category:Software Reviews]]
[[Category:Software Reviews]]

Latest revision as of 20:27, 28 May 2023

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: claws@vnet.ibm.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 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 tp 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.

1.3.5 CONTROLS

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:

   BUTTON
   COMBOBOX
   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.

Summary

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.

References

  • 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