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

From OS2World.Com Wiki
Jump to navigation Jump to search
No edit summary
Jugbogdan (talk | contribs)
mNo edit summary
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”'''
'''“Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation”'''


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,
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)
Windows, and/or DOS applications. Prior to graphical user
and Microsoft Windows, screen reader products for DOS had little difficulty accessing the text-based information
interfaces (GUIs) such as OS/2 Presentation Manager(*) (PM)
displayed on computer screens. The advent of GUIs has significantly complicated the ways in which any screen
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.
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!
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
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.
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:
A Screen Reader/2 system consists of the following
components:
 
* IBM Personal Systems-compatible computer
* IBM Personal Systems-compatible computer
* Operating System/2 Version 2.1 or later
* Operating System/2 Version 2.1 or later
Line 55: Line 34:
* Screen Reader keypad connected to a mouse port or Screen Reader adapter
* Screen Reader keypad connected to a mouse port or Screen Reader adapter
* Text-to-speech synthesizer connected to a serial port
* 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.
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
To get information that is not spoken automatically, you use the Screen Reader/2 keypad.  Arranged like a United States
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
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.
keys, performs a specific screen-reading function.


Keypad functions and procedures for automatically speaking
Keypad functions and procedures for automatically speaking screen information are defined in profiles.  Profiles are
screen information are defined in profiles.  Profiles are
developed for PM, Windows, and DOS applications using Screen Reader/2's Profile Access Language (PAL).
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
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 controlsWhen an application starts, an additional application-specific profile may be activated to handle key sequences and information spoken for unique features of an applicationApplication-specific
does not have immediate access to text and icons displayed
profiles are not required to make an application accessible, but they often provide easier access to an application's screen information.
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) databaseThis 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===
==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.


A screen reader recognizes text more easily than anything
==1.3  Access tp the Graphical User Interface==
else on the display. Screen Reader/2 captures text before
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
it is converted into and displayed as part of the graphical
operating system hooks, and from the off-screen model of the display.
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.1 GUI Text===
AND CONTROLSPosition static text for a control
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.
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 BOXESGive each group
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.
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
GROUP SETS OF CONTROLS USING GROUP BOXES. Give each group box carefully chosen textScreen 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.
not announced together by Screen Reader/2.


An entry field and arrow buttons in  a  group  box  are
An entry field and arrow buttons with text to the right are not announced together by Screen Reader/2.
announced together by Screen Reader/2.


===1.3.2  ICONS AND BITMAPS===
An entry field and arrow buttons in a group box are announced together by Screen Reader/2.


A BITMAP is a representation in memory of data displayed on
===1.3.2  Icons and Bitmaps===
the screen.  An ICON is a pictorial representation of an
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.
item, such as a data object, system action, or minimized
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.
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
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.
checksum for the bitmap and associates the checksum with the
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.
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,
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.
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
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
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.
collection of icons together with text.


An icon-based menu with no associated text is not accessible
An icon-based menu with no associated text is not accessible without sighted assistance.
without sighted assistance.


A text-based  alternative can be provided through an option
A text-based  alternative can be provided through an option in a settings notebook.
in a settings notebook.


===1.3.3  WINDOWS AND THE SCREEN READER/2 VIEW===
===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.


Most of the time we think of an OS/2 window as a frame
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
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.
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
a pushbutton, for example, then the Screen Reader/2 view may
contain only the pushbutton and the blind user will lose application accessibility.
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
The worst nightmare for any screen reader is losing sight of
screen keyboard input is directed and what effect the input will have.  Without this information the application is
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.
unusable.


In text mode, the symbol displayed on the screen showing
In text mode, the symbol displayed on the screen showing where text will be placed is called the cursor.  For
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
text-mode applications, Screen Reader/2 finds the cursor
position in a data structure associated with a logical video
buffer.
buffer.


The corresponding cursor object in the graphical user
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.
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
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.
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
USE THE STANDARD PM AND WINDOWS CURSORS instead of creating your own cursor.  If an application creates its own cursor,
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.
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
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.
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===
===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
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.
documented in the toolkit books for PM and Windows.


USE THE PREDEFINED CLASSES OF CONTROLS DEFINED IN THE PM AND
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:
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 268: Line 129:
     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 280: Line 138:
     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
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!
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===
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.


In general, blind users must use keyboard keys rather than a
===1.3.6  Keyboard Access===
mouse. Keyboard keys are usually documented as part of a
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.
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
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.
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:


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


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

Revision as of 22:15, 19 October 2018

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