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