Print Friendly, PDF & EmailPrint or Convert this page to PDF

Development Of An Accessible User Interface For People Who Are Blind Or Vision Impaired As Part Of The Re-Computerisation Of Royal Blind Society – 1992

copyright (c) 1994 Tim Noonan

By: Tim Noonan – Adaptive Technology Services Manager tim@timnoonan.com.au

Abstract

In 1991, Royal Blind Society (Australia) and Deen Systems, a Sydney-based software development company, undertook a major overhaul of RBS information systems intended to enhance access to RBS client services as well as employment opportunities for blind and vision impaired RBS staff. This case study outlines the steps taken and principles followed in the development of a computer user interface intended for efficient use by blind and vision impaired individuals.

INTRODUCTION

As part of an upgrade of its online computer systems and applications, Royal Blind Society (RBS) has collaborated with Deen Systems (DS) in the development of a new user interface optimised for access by blind or vision impaired (BVI) people. The design and special features of this user interface are the main focus of this article. “User interface” refers to those aspects of a computer program which display information to the user and which interpret and/or elicit input (i.e., commands to be issued from the keyboard) from the user. Because the user interface described below is intended for use by vision impaired people, it is referred to here as the VI interface to distinguish it from the regular interface.

Three main groups of business applications will ultimately be available in this integrated environment: marketing and fund raising system, client tracking and service delivery statistics system and, finally, a system to track and coordinate the production of alternative format materials and to handle circulation and cataloguing of library materials.

Screen reading programs for MS-DOS are all tailored to provide access to DOS applications. When developing an application on a remote computer using a terminal program to access that application, the remote application has no way of taking advantage of hardware aspects of the PC as PC-based programs sometimes do. For example, DOS programs can send material to the screen in two ways: one which will speak, one which will not. Programs on a PC can use scrolling text, highlighting and reliable use of cursor keys and remain compatible with most modern adaptive technology. Remote applications can cause major compatibility problems with adaptive technology when they employ similar facilities; this article describes our experiences with and solutions to the issue of compatibility.

OBJECTIVES OF THE DEVELOPMENT

Following a major review of RBS’s information technology requirements in 1990, Deen Systems, as part of a consortium, successfully tendered to undertake the development of RBS’s new business systems. Deen Systems was responsible for the database design and programming of the online systems but RBS worked very closely with Deen Systems in the development of an accessible VI interface. We began with a list of basic screen design principles (see below) and jointly came up with solutions to material which was more involved than the basic principles could deal with.

Adherence to the following principles was fundamental to ensuring that Deen Systems and RBS did not lose sight of the basic requirements for consistency and minimal differences between the regular and VI interfaces. Our guiding principles included:

  • develop an interface which will enable remote clients to access information directly – e.g., to Library Services.

  • contribute to people’s understanding of methods of man- machine interaction, and in particular to add to our knowledge of VI accessible user interface design;

  • stimulate others to make a commitment to efficiently accessible systems for people with disabilities;

  • develop a work environment in which blind and vision impaired (BVI) people can seek and achieve promotion in the workplace;

  • Develop a system which relies minimally on advanced or product-specific features of adaptive technology access software and hardware. We wanted to develop a generic system which could be accessed with the widest range of adaptive technology. This is why we did not leave the adaptive technology to deal with overly complex screens, even though one or two systems may have been able to do this to some extent with detailed configuration.

  • minimise the duplication of software development by modularising the user interface aspect of applications rather than specifically modifying each application for accessibility. We wanted to minimise special coding, of course, but it was DS who actually had the architecture which made this possible. They made substantial alterations to their applications generation system (4GL) to enable the user interface to be kept separate from other code.

HARDWARE AND SOFTWARE ENVIRONMENT

Our new online systems are being developed in a UNIX environment. UNIX is text-oriented, making it compatible with major adaptive hardware and software products by use of terminal emulation software on a PC. UNIX also provides machine-readable documentation which is accessible to all users, as well as a variety of text processing utilities. UNIX is in a good position to become the preferred text environment for BVI people in the 90s as DOS becomes displaced and outdated by the continuing move towards graphical user interfaces and multi-tasking.

All of our online users have access to an MS-DOS PC to access the Unix computer. For BVI users, this PC is equipped with speech, braille or large print technology to enable access to programs on the PC as well as the UNIX applications. We find that MS-DOS Kermit version 3.12 works ideally with adaptive technology devices. While most PCs are equipped with Ethernet connections to the UNIX machine, serial and modem connections are also in use and work well with the VI interface.

Our applications are based on the INGRES Relational Database Management System (RDBMS). Because we will have three or more applications, each sharing much common data (e.g., names and addresses), an integrated relational data base which is managed independently allows us to minimise duplication of data, ensure data integrity, and provide very flexible reporting.

The applications are written in a fourth generation language called Ochre. Fourth Generation Languages are now commonly used for the design of business and database applications. 4GLs aim to minimise the time spent writing lines of code for common tasks thus leaving the programmer time to concentrate on the “what” that the program is supposed to do, and the 4GL deals with the “how” of low level programming. 4GLs allow a more humanly readable program to be written and then convert this into thousands of lines of low-level code which is executed by the database management system behind the scenes.

Advantages of Ochre include:

  • Ochre allows programs to be quickly prototyped. Rapid prototyping is a method of application design which involves creating several prototype versions of the software during its development. Because we have been covering such a lot of new ground in our user interface development, rapid prototyping has allowed testing with adaptive technology users and devices at very early stages. This has been very effective.

  • Ochre allows the business functions of the organisation to be separated from the input/output components of the system (the user interface). This clear separation of business functionality from user interaction has enabled us to eliminate duplication of programming in the development of two discrete user interfaces. It also offers us the option of adding new user interfaces in the future without requiring major alterations to the program.

  • Ochre was developed in Sydney. Because we have been dealing directly with the authors of Ochre, we have been able to have extensions added to the programming language itself which greatly assisted the development of the VI user interface.

  • The screen output routines of Ochre were totally re-worked to ensure accurate and meaningful voice output. These changes included ensuring that screens are written from top to bottom (not in a less structured order), screens are always cleared before new text is written to them, field names are re-displayed after a cursor movement command to automatically prompt the user verbally, and error messages always trigger a bell. These and other enhancements are now an integral part of the commercial Ochre product. To our knowledge, this is the only 4GL designed with the needs of VI users in mind.

GUIDING PRINCIPLES OF THE USER INTERFACE DEVELOPMENT

Some of these principles were set out before development of the user interface, others were recognised as we moved further into the development process.

  • Sighted and BVI staff MUST ALL be able to access the new applications efficiently, accurately, and with confidence. We decided to develop two user interfaces, optimised for sighted and blind users respectively. Any user can choose either the VI or the regular interface before starting the application. Our experimentation demonstrated that developing a single user interface to meet the needs of both groups of users would have compromised efficiency, accuracy and confidence for both groups.

  • Users of both interfaces employ identical keystrokes to interact with the programs. We considered this aspect of design to be essential to ensure effective training, documentation and support, and to ensure meaningful communication between users of the system.

  • Screens may differ in presentation, for each group of users, but in most cases the VI screens are a less embellished version of the sighted screens. This commonality allows sighted users to be able to understand VI screens when working with a BVI colleague on an issue.

  • All information from the application available to sighted users is also available to BVI users. It sometimes took quite a bit of experimentation to develop a way of making some information meaningfully available to BVI users, but it was considered essential to ensure this.

  • Punctuation characters are extensively employed to provide screen layout, colour and context information to users of the VI interface. Examples of punctuation used include the colon (“:”) to indicate that a field can be updated, the equals (“=”) character to indicate that a field is only for view, and the semicolon (“;”) between column headings on summary screens.

  • The system provides both menu-driven and command-based modes of operation. BVI users are likely to take the time to learn the more rapid command approach because of the time it can save by eliminating intermediate screen output, and all users can employ the interaction approach most suited to their style, while hopefully becoming more efficient over time also.

  • simple and clear rules for screen design so that all users can quickly master the systems. This will also mean that future client access to related systems should be more straightforward.

  • We did not want to develop and maintain two different systems (one for sighted, and one for BVI users). By using Ochre we have been able to develop one primary program which points to either of two user interfaces. For each “sighted” screen there is a VI equivalent, as well as general rules in Ochre about how such information should be displayed for VI users. At this stage we have two user interfaces, but Ochre can deal with additional user interfaces tailored for future users and equipment.

  • The system provides a variety of word completion, spelling validation and context-bound choices to maximise efficiency and accuracy of user interaction with the application. For example, when entering an address, the user is prompted by the system to enter the state, then the place name; post code and zip are automatically inserted by the system. If a user enters the first few letters of a place name in the state nominated, the system generates a menu of valid place names to choose from. Similarly, once a place name has been selected the street can be partially entered and the system nominates a small number of valid streets for that place name. These facilities ensure accurate data entry and are very useful for BVI people who do not see place names and street names on a daily basis and would often be less certain about their spelling.

  • We made minimal assumptions about the adaptive technology and computer used by the BVI user. After significant discussion and experimentation, we agreed on a minimum access standard of a VT-100 terminal emulator with keyboard mapping, and any speech, braille or large print system. Keyboard mapping and cursor addressing are essential for total compatibility with the interface for sighted users.

SCREEN DESIGN ISSUES

Screen layouts and field ordering must all be well-defined. A limited set of “standard” screen layoutss were defined for sighted and VI interfaces. Except in rare special circumstances, such screen standards are used. Some of the screen design principles we follow are:

  • Field order on each screen is from most to least significant. Listening is sequential from the top of the screen, so order is very important.

  • Headings and messages always appear in consistent screen locations. For example, each screen’s unique title is on line 1 and the screen layout type appears on line 2 (such as “list of values” or “update”); similarly, error messages always appear on line 24, and a more complete explanation of the error is always found on line 23.

  • Where possible, only one field should appear on a screen line.

  • No ornamental characters or borders should appear on VI screens.

  • Highlighting and colour should not be used in isolation to provide significant screen information. Punctuation is often used to convey this information. In situations where a cursor is moving from one field to another, highlighting of the current field should be avoided or fields may be verbalised multiple times; highlighted text is repeated because in order to highlight part of a screen, it is necessary to delete the material to be highlighted, send a “highlight on” code, which is followed by the text and a code which instructs the system to turn highlighting off. This obviously means that the text gets read again as it is highlighted. (Imagine a menu which includes one highlighted item. Consider what happens when you “unhighlight” one item and highlight a second item. First, the originally highlighted text is removed from the screen and re- sent as unhighlighted text (which is spoken); second, the un- highlighted text of menu item two is deleted and re-sent as text surrounded by highlighting codes (spoken) and so on. Consequently, both the material being un-highlighted and the material being highlighted are re-verbalised, making clear, unambiguous interpretation difficult.

  • Each new screen should fully overwrite previous screen information (no pop-up windows, etc.). Speech output systems work on a line basis, so old information at the start or end of a screen line can cause major confusion. If a line on the screen is being altered, the whole line should be cleared and then re-sent to the terminal. Failure to do this may result in limiting speech output to those characters being changed, resulting in unintelligible speech output.

  • Fields which are too wide for the screen should be identified by the “>” sign, and a means of viewing such fields in full must be available; this is because horizontal scrolling (a long line moving from left to right) can be totally meaningless and for users of speech, each time the line moves it is re- announced, causing confusion.

  • Error messages must always include a bell to attract the user’s attention;

  • If the system changes to a new screen without being instructed by the user to do so, a bell should be sounded to alert the user that a screen change has occurred.

  • Only one item is displayed on the screen at a time from a vertically scrolling list. This is because most speech programs cannot cope with multi-line scrolling regions over a VT-100 style terminal link without re-reading lines multiple times.

  • When a single line summary of an item is displayed, there should also be a way of viewing the summary in a line-by-line basis; and,

  • For VI users, menu options (which in our system normally appear at the bottom of each screen) are not automatically displayed until the menu key is pressed. This saves time and increases clarity of screens.

CONCLUSION

We began the planning and development of this system at the start of 1991. We now have our marketing and fund raising systems completed and they are being used extensively by sighted and BVI staff. Although it is recognised that there are further enhancements which could be made to the user interface, the objectives of easy and efficient access to the systems by all users have been achieved.

Working with Deen Systems provided a unique opportunity; as developer of both the programming language (Ochre) and our online applications, Deen Systems’ programmers brought an in-depth understanding of all levels of design to each stage of the development process. This collaboration has benefitted both RBS and DS. RBS has greatly enhanced the ease and efficiency of access to its systems by both sighted and BVI users; Deen Systems came away with a superior product and greater understanding of the needs of computer users with disabilities.

** At the time of writing, Tim Noonan was Adaptive Technology Services Manager at Royal Blind Society. He headed a multi-disciplinary team responsible for providing such services as adaptive technology assessment, training vision impaired people in the use of computers, and the dissemination of product information. Tim was also responsible for the development of systems to improve alternative format production processes and to generally improve the accessibility of RBS positions and activities.**

website by twpg