Go to previous article
Go to next article
Return to 2004 Table of Contents
RL & Associates, Inc.
340 Bryant Street, Suite 205
San Francisco, CA 94107
Discussing your assistive needs during the planning phase of software upgrades or migrations will provide benefits to your whole organization.
As users of assistive technology, we tend to have the attitude that our needs will present a burden to our employer, or may be viewed as an outright barrier to employment. But in many cases, accommodating our needs can actually provide benefits to the organization we work for.
It is vital that employees who require assistive technology be included during the early planning stages of software upgrades, migrations to new software, or the development phases of proprietary, in-house or third-party software. This advance planning saves time and money by increasing the productivity of the employee in question and by reducing the support time that they require from fellow employees.
When employers consider the needs of employees who require assistive technology, they can make better software buying decisions, which will benefit all users of such software. Knowing the keyboard alternatives to mouse clicks actually saves all users time as they use the software. Keyboard control can also be less fatiguing for the wrists and arms than using a mouse. When software has a flexible user interface, it is easier to learn, since generally speaking, there are more ways to perform any given task. People have an easier time with such software because they use whichever method is easiest for them to remember, faster, or ergonomically more comfortable. User interfaces that are easier for those who require screen readers and or large print also tend to work better for all users.
The following situations illustrate how accommodating an employee with special-access needs can benefit the employer in ways that are not readily apparent at first glance.
The first situation involves creating an accessible interface to a donor database. This database was originally created in Microsoft Access and presented some significant challenges to the user, who was blind and also had a learning disability. The original interface was inconsistent across the various functions and required the use of the screen reader's mouse-pointer function to allow the user to read information created by the various reporting functions.
We were requested to create a new interface, which had to be easy to learn, have enough power to provide all the functionality for the user to perform his job, and was consistent across all functions.
The original database maintained the data for all donors, their donations, contact information, and instructions for the drivers who collected the donations. Its problems were that it was not consistent in its mode of operation, some of the output generated was not easy to navigate making it difficult for the user to extract information without using extensive screen reading functions, and some functions that the user needed were not implemented.
The original request required that the user be able to conduct searches on a number of fields, modify contact information, generate legible output for the drivers, and create some report information.
Our proposed solution included using a new database-management system hosted on a Linux platform, a web-based interface, and built-in scalability. A web-based interface solution provided a much more consistent interface, all functions were accessed through the same type of screen layout , and reports could be generated in a variety of formats to increase legibility.
Additional benefits to the company derived from the proposed solution:
The user was able to learn the interface quite easily. He was able to enter, search for, and modify information in the database with-in a few training sessions. He easily understood the layout of the screen and was able to read information generated by the database's reporting functions. He was also able to perform a variety of other functions that were not in the original database program. Most importantly, he was able to use the interface without extensive use of complicated, screen-reading functions.
Flexible Software Design
The next example involves a software migration from a DOS-based environment to a Windows-based Graphical User Interface.
The original environment:
Some problems existed when switching between the DOS database and the Windows-based applications, both of which the user was required to work with. Because of memory limitations of the DOS environment, the database application was sometimes unreliable and the screen reading functions could occasionally be lost. Switching between the DOS database application and Windows Apps was also inconsistent.
Migration to Windows based software:
The company decided to migrate all computers to Windows 2000 for security reasons and because the database software provided an easier interface in Windows. Additionally, all memory problems disappeared in the Windows 2K environment.
Problem with new database:
The new database is written in Visual Fox Pro. It uses the same controls for all its fields. This makes it difficult for the screen reader to determine if it's looking at a "list-box", a "Combo-box", or an "Edit-box".
Why the company decided to use a Graphical User Interface (GUI) versus a text-based one:
A properly designed GUI can be quite simple to learn and the consistency of the GUI across all aspects of the software makes it easy for the user to explore functions they have previously not used.
Problems with GUI interface:
When scripting JAWS to work better with the database, we found that detecting color changes did not function properly; we had to use other functions in JAWS to achieve the same result.
Steps we took to adapt the interface:
Additional benefits to the company because of the modifications:
The company wanted hotkeys to be available to all reservationists because they wanted to minimize mouse movements and clicks. We were able to achieve this. Because we had to go through the software to determine its level of access, we were able to test for that function and therefore they did not have to do it again, saving them time and money.
The last situation involves a government entity, which was providing accommodation to an employee who needed to access their internal Intranet and their public web pages.
Their web developers were able to learn about the needs of this employee and address his access issues and in the process made their web pages much more accessible to the public at large.
Addressing Intranet access may have significant benefits to the company; when an employee needs access to corporate Intranet pages and the employee has to use a screen reader, the web pages need to conform to the standard designated by the W3C consortium for accessible web pages. If the employer addresses these issues during the planning and implementation of their corporate Intranet, they will already be accessible if they decide to deploy some of these pages to the external Internet as publicly available web pages. The company's web designers will already be familiar with the construction of accessible web pages, allowing them to design pages that have both compelling content and full accessibility.
Addressing access issues in the planning phase may save your company money and human resources.
Using a browser-based interface and accessible web pages not only provides an easy-to-use solution for the individual with special needs, but also provides compelling content and ease-of-use for everyone else.
Properly constructed software with standard Windows controls will yield benefits when Visual Basic, or other scripting/automation utilities, are used, because the scripts need to perform fewer functions to determine that they are performing the action on the correct content.
When the needs of assistive technology users are addressed during implementation, the accommodation only helps those users. By contrast, when accessible standards are incorporated during the design phase, all users benefit from the increased ease of use.
Go to previous article
Go to next article
Return to 2004 Table of Contents
Return to Table of Proceedings