Presented at the CSUN conference earlier this month, below is a
draft, incomplete report on Windows database accessibility.  In
my opinion, it is pioneering, much needed work in this area,
which has been persistently difficult for blind people in gaining
productive usability.  I encourage others to share tips on
selecting and configuring accessible combinations of database
programs and screen readers.

Regards,
Jamal

----------
 ACCESS TO DATABASES:  WHAT DATABASE PROGRAMS CAN
WINDOWS USERS WITH VISUAL IMPAIRMENTS USE?
Draft March 11, 1999
Crista Earl
American Foundation for the Blind
11 Penn Plaza Suite 300
New York, NY 10001
(212) 502-7605
[log in to unmask]

Description of problem
For visually impaired computer users who use Windows-based screen
readers, database access lags access to other core types of
applications such as word processors, spreadsheets, browsers, and e-
mail packages.  Few users express complete inability to use a word
processor or e-mail package (see AFB's survey of Windows screen
reader users) and many users are freely able to change from an
inaccessible word processor to one which suits them better.
Databases, however, are selected on the basis of the type and amount
of data to be stored and the types and levels of access to be allowed.
Once a database program is chosen, one user within the group of
potential users cannot usually opt to access the data through another
program.  Therefore, if the interface used by all employees within the
company or patrons of the library or visitors to the web site does not
allow the use of a screen reader, blind users are excluded.

Database interfaces are far more inaccessible to blind users in
Windows than they were in DOS, relative to other core types of
applications.  For this reason, many visually impaired users are
continuing to use DOS-based database programs when they have a
choice.

The ability to use database applications is essential to employment as
has been shown by AFB's survey of Windows screen reader users
and by a review of help-wanted advertisements in on-line newspapers.

In the process of enhancing screen reading software to give access to
a wider range of Windows-based software and to enhance the
efficiency with which skilled screen reader users are able to work,
screen reader manufacturers have incorporated features to make
accessible the most essential word processing and browsing features.
However, little has been done by screen reader manufacturers,
mainstream software manufacturers, or computer accessibility
advocates to improve the database situation.

One major factor in the slow improvement to database access is the
skill level required to effectively use many databases.  The vast
majority of computer users are stuck at the "perpetual beginner" level
and few have the technical expertise to manage a sophisticated
database.  Blind database users must have the same technical skills
as any database user, but must also have screen reader skills to use
these programs.  This results in a very small field of users from which
screen reader and database manufacturers can expect reasonable
help in making better products.

INTERSECTIONS BETWEEN USERS AND DATABASE PROGRAMS
Another reason development has been slow is that not all users need
the same level of access or access to the same features of the
database.  Any user of a word processor needs to be able to type
words and characters, delete, insert, and most need to run a spell-
checker.  Most need to be able to determine where text will appear on
the printed page.  People who use browsers all need to be able to
read pages and fill out forms.  In the case of the database, however,
users fall into three broad categories:

Those who design and create databases.  These users need to add
and remove fields, create the relationships between database
elements, and design and lay out the user interface.

Those performing data-entry tasks:  these users need to be able to
enter and edit data, but may not find it necessary to add or delete
fields.  They must be sure which field they are working with and what
special instructions might be available.

Those who use the output of the database:  a broad base of users may
be able to query the database and view information in a controlled
manner, but may have no control over the content of it or its storage.

When users say, "Does this screen reader work with Microsoft
Access?" what are they really asking?  When a user says, "I'm using
Paradox and it works just fine," from what point of view is this user
reporting accessibility?

We have evaluated the databases in this study from these three points
of view:

Can blind users using screen readers design the database structures
themselves?  Can these users add new fields and make other
changes to the structures?  Can these users lay out data-entry and
report forms?

Can blind users with screen readers enter and edit data reliably?

Can blind users using screen readers look up data and view the
results?  What must be done in order for this to be possible?

Often the greatest number of users of a particular database
application are given limited access through a user-interface created
with a third-party tool.  Do these allow for adequate screen reader
access?  Do they improve access to the most unfriendly databases?

What we have not Done
Most importantly, we have not released the potential buyer of
database software from the important task of careful shopping.  We
cannot advise you as to the suitability of one database or another for
your networking environment, your number of users, your amount of
data, or other considerations not related to access by blind and
visually impaired users.  Selecting a database is a complex process.
Suitability for blind users is one major consideration.

Characteristics of an Accessible Database
Of course, an accessible database must conform to the same
standards that any software package must.  We have selected the
most crucial and relevant of these characteristics and looked for them
in the databases we tested.
Standard Controls
Do these programs use edit boxes, check boxes, menus, and other
controls understandable to a screen reader?  Are these controls used
in all aspects of the program?
Keyboard Access
Can all aspects of the program be used without a mouse?  Can users
move from field to field, select field and tables for manipulation, and
place fields and other controls on data-entry forms by using keyboard
commands?

Standard Means of Displaying Focus
Does the program place a caret in the data-entry field?  Do buttons in
dialog boxes receive focus?
Explicit "Status Information
Does the program explicitly display status information?  If the
database is processing a lengthy query, does it display "Processing
query..." in a way that can be read by a screen reader?  As the user
moves from one record to another, does the program indicate "Record
1 of 1759?"

In addition to the usual access considerations, there are features
which database users find helpful.  For example, it is desirable to be
able to easily display related information  on one line, such as field
name and data in a data-entry form or related fields of one record on a
line in a report.  It is also desirable for the program to allow query
results and reports to be saved in files of a generic form, such as
ASCII or HTML for Brailling.

assessment of specific database programs
Databases fall into four general categories:
home/light duty
medium-duty, medium features
full-featured, high volume
Special-use databases (contact tracking, library card catalog, etc.)

Process:
Testers first attempted to create simple name-and-address database
structures in each of those products that have such capability.
Several popular screen readers were used in order to determine the
range of users to which the product would be accessible.  Where
visually impaired testers were unable to create these databases,
sighted users created them for the next phase.  Since some special-
use database programs do not allow users to create structures but
come with predefined sets, these predefined structures were used for
the remainder of the test.

In the second phase of testing for each product, testers entered data
into the structures created in the first phase.  Inaccurate information
was entered and later corrected by the testers.  Notes were made on
special tricks and work-arounds that needed to be employed in order
to accomplish these tasks.  As in phase one, several screen readers
were tested with the databases.

In the third phase, several simple and at least one (where possible)
more complex queries were set up and users were asked to read the
results using Windows-based screen readers.  As always, several
screen readers were used in the tests.

In the fourth phase, third-party products were used to design and test
data-entry and query screens to access the structures created in
phase one.  Since not all products tested in phase one allow such
access by available third-party interfaces, not all were used in the
tests.

Recommendations
We have focused our attention on the answers to the following
questions:

My company uses a specific database program.  Can blind
employees/customers use it?

What screen readers can I (not) use with this database?

Which databases are possible solutions for my needs as both a
database user and screen reader user?

What tricks do I need to know to help me get the most out of my
database and screen reader when I use them together?
Databases:
Products tested in this study were: Paradox 8.0, Microsoft Access 97, Act!
4.0, Visual FoxPro 6.0, Maximizer 5.0, and Filemaker Pro.

The third-party interface product tested was Visual Basic (versions 5.0 and
6.0).

Corel Paradox 8.0
Creating a Database with Paradox 8.0

Paradox uses "Experts" to help the user with specific complex tasks, including
setting up new tables.  The opening screen is one of these Experts.  These
screens use a peculiar interface that does not include standard radio buttons or
other familiar controls.  It is possible, however, to move around the window
with the screen reader's mouse navigation keys and to click on desired options.
It also turned out to be possible to press Alt-G followed by Alt-N to select the
option to "G"I've a name to a new database and continue.  Subsequent Expert
screens had a similar, somewhat speech-hostile format.  It was not possible, or
at least not expedient, to create the first table in the database using the Table
Expert as this screen provided lists of possible field names and associated
controls in a "flat," undifferentiated screen.  Choosing to build our own table
proved much more effective.

In Building our own table, we found that all functions we needed had
keystrokes associated with them.  We also found that a help message appeared
for each operation and that screen readers with a feature to read such regions
could be configured to work well here.  The typing of field names and
associated information was somewhat problematic because the Paradox
interface did not provide a caret, but a skilled user of the screen reader was
able to manage the task.

Creating Forms in Paradox 8

Creating the simplest data entry form was quite easy and presented no screen
reader-related difficulties.  Further customization of the form, however,
required drag-and-drop capability with the mouse.  Further, Paradox provided
no orientation marks such as column and row indicators by which to align
objects.  Laying out any but the simplest form in Paradox is nearly impossible
without vision.

Entering Data in Paradox
Table View
By default, a user entering data in a newly created Paradox table is presented
with a columnar display with field names centered at the top of each column.
Each record is displayed as one row in the column.  The user moves from
column to column by using the left and right arrows or the tab and shift-tab
keys.  When the last field in a record is reached, Paradox wraps to the next
record.

Paradox indicates the "current" field by displaying it in a contrasting color.  Its
corresponding field name is not differentiated from the other field names.  The
record number is displayed in a predictable location on the screen, making it
easily available to screen readers with features to read specific regions or to
look for specific text.

Form View
Paradox provides the ability to create custom data entry screens.  In theory, a
custom screen ought to provide the ability to create a form more friendly to
screen readers than the default tabular scheme.  For example, The field name
and field input area could be placed on the same line.  The designer of the form
could guarantee that no other fields shared the line.  Input fields could be
aligned vertically so that screen reader users would know where to look for
them.  Alternatively, designers could arrange the input fields a predetermined
distance from the field name.

Although many of these options exist in Paradox, one major feature is missing.
In a form view, as in the table view, no caret is displayed.  The Tab key and
arrow keys move from field to field, but it is difficult for the blind user to
determine which is the current field and which character within the field is
about to be deleted, for example.

Viewing Data in Paradox: Reports and Queries
By default, reports are displayed in "flat" view windows with no cursor.
Screen readers can easily read the data and PgUp and PgDn keys move up and
down by screenful.  Screen reader commands can be used to read and spell
details, but it is up to the user to decipher columnar information.

Exporting Reports to other formats:

Microsoft Access 97
Access 97 was unique among these databases in that at least one screen reader
manufacturer has put special effort into creating Access-specific
configurations.  As a result, Access worked far better with JAWS than with
any other screen reader.

Much of what Access displays on the screen is not available to most screen
readers.  In addition, several important functions cannot be performed without
mouse or screen-reader drag-and-drop ability.  With any screen reader but
JAWS for Windows, Access was the least accessible of the databases tested.
With JAWS, many functions were difficult, but Access was usable by a skilled
user.

Creating a Database in Access

Entering and Editing Data in Access

Viewing Data in Access

Visual Foxpro 6.0

Special-Use Databases
Maximizer
This product comes with pre-defined structures especially suited to certain
activities.  For example, the S.O.H.O configuration features contact-tracking
for small offices.  With the "light" version of the product, the amount of user-
configurability is minimal.  Maximizer offers a development kit which was not
tested.

Modifying user-defined fields
Although Maximizer, in its basic form,  does not allow the building of
databases or tables, it does allow users to modify "user-defined" fields for their
own use.  This feature was quite accessible.  Dialog boxes with standard
controls were used throughout.  The only difficulties arose when

     1.   Maximizer did not always allow the tab key to move to the New Field
     button (W-) when moving forward through the dialog box.  Moving
     backward with Shift-Tab did work.  Also, pressing alt-W accessed the
     button.
     2.   When selecting from a list of items, it was not apparent that multiple
     items could be chosen.  Selection was indicated by a graphic that had to
     be labeled in order for the screen reader to announce selection.  These
     issues were easily solved.

Entering and Editing Data in Maximizer
Maximizer uses standard, screen-reader-friendly edit boxes and other controls
almost exclusively.  When entering or editing a record, each field is presented
as an edit box with a cursor.  Editing data is easy and presents no significant
access problems.

Viewing data with Maximizer

Act! 4.0
Act! Is primarily a contact tracking system, but has many advanced features
that make it flexible enough for many general-purpose database applications.
It has features, such as an appointment calendar, which would not generally be
considered database features which we did not evaluate and may not be readily
usable by blind users.  Here, we evaluated only the purely database functions.

General Interface
Act! Uses standard Windows menus.  Hot keys were available for many
common functions.  Most dialogs used standard controls, although some
custom controls were used in key places.  Some dialogs used an unusual
scheme of "nested" tab controls, which was difficult to use from the keyboard.
Screen-reader-based mouse navigation on the tabs was effective.  In these
dialogs, the tab key moved forward through the controls, but the shift-tab key
did not always move backward in the same order.

Creating a database using Act!
Act! Comes with a pre-defined contact-tracking system.  The user has no need,
and nearly no ability, to create a new form of database, but there are unlimited
"user fields" which users can name and place in the data entry windows.
Default field names and types can also be changed.

Changing the name and type of a user field was fairly easy with speech.  The
option was available from a menu and the settings were entered in a dialog box
with standard edit boxes, but this dialog included the "nested" tab controls
mentioned above.  A skilled user was able to easily accomplish the task.

Placing fields in specific locations on the data-entry form was far more
difficult.  The design screen displayed fields and gave no keyboard navigation
ability among them.  When moving with the screen reader's mouse, little
feedback was provided.  Fields could be moved by right-clicking with the
screen reader's command and then choosing one of several options, but users
were unable to determine the new location of the field.  In general, screen
layout manipulation was not possible with a screen reader.

Data Entry with Act!
Act! Features an extremely screen-reader-friendly data entry and data look-up
interface.  Edit fields are displayed in standard edit boxes with cursors.  Field
names are usually displayed in a predictable position relative to the data field.
A few field names, such as phone number fields, were not read by screen
readers, but generally navigating within one record could be accomplished by
beginning users.  Many fields have "drop-down lists" which were displayed in
list boxes.  Single items and adjacent items could be selected from the
keyboard, but not non-adjacent items.

Some departure from screen reader defaults was necessary in places.  For
example, it was necessary to set JAWS for Windows' "Search for Prompts" to
maximum in order to hear field names when tabbing from field to field.  It was
also necessary to set a "user window" in Window-Eyes in order to have
records read in the "Contact list."  For the most part, however, Act! Worked
well without modification to its interface or to screen reader settings.

Viewing Data in Act!
Browsing
use of an Act! Database Can be limited for some users to "browsing."  In this
mode, records are displayed as in edit mode, but the edit boxes are marked as
read-only.  This means that the user cannot edit the field but has all navigation
available to users who can, including the use of the cursor within the edit field.
This is a very desirable approach to allowing browse-only access as it provides
standard controls and keyboard navigation necessary for use with a screen
reader and requires no extra knowledge on the part of the browsing user.

Reports and Queries in Act!
Act! Provides a number of standard reports.  These reports, which have a
simple layout with clearly labeled "fields," can be sent to the usual output
devices: screen, file, or printer.  To the great benefit of screen reader users,
however, Act! Also offers "editable text" as an option.  In this case, the report
is brought up in a word processor and the user can navigate with normal,
familiar word-processing keys.

Query results can be displayed in a one-record-per-screen format identical to
the editing screen or in a list format.  The list format requires some, in some
cases quite a lot, of screen reader configuration to be useful.

** Visual Basic as a "Front End"

Database Contact Information
Maximizer 5.0:
Multiactive Software, Inc.
1090 West pender Ave. 9th Floor
Vancouver, BC  V6E 2N7
Phone:  (604)601-8000
Fax:  +1 (604) 601-8001
[log in to unmask]
www.maximizer.com

Act! 4.0
Symantec Corporation
www.symantec.com

Microsoft Access 97:
Microsoft Corporation
One Microsoft Way
Redmond, WA 98053-6399
www.microsoft.com

Visual FoxPro 6.0:
Microsoft Corporation
One Microsoft Way
Redmond, WA 98053-6399
www.microsoft.com

Visual Basic:
Microsoft Corporation
One Microsoft Way
Redmond, WA 98053-6399
www.microsoft.com

Paradox 8.0:
Corel
www.corel.com

----------
End of Document


VICUG-L is the Visually Impaired Computer User Group List.
To join or leave the list, send a message to
[log in to unmask]  In the body of the message, simply type
"subscribe vicug-l" or "unsubscribe vicug-l" without the quotations.
 VICUG-L is archived on the World Wide Web at
http://maelstrom.stjohns.edu/archives/vicug-l.html