2004 Conference Proceedings

Go to previous article 
Go to next article 
Return to 2004 Table of Contents 


Victor Tsaran
Karolina Tsaran
Bartimaeus Group
1481 Chain Bridge Road, Suite 100
McLean, Virginia 22101
Email: victor@bartsite.com 
Email: karo@bartsite.com 

The primary goal of Section 508 is to enable easy access to electronic and information technology for people with disabilities. "Under Section 508 (29 U.S.C. ' 794d), agencies must give disabled employees and members of the public access to information that is comparable to the access available to others"1 It sounds fair and encouraging that the disabled people should have access to information "comparable" to that of the general public. It has often proved, however, to be a controversial issue for those responsible for the implementation of Section 508 and for those who are its target population-the disabled people. In this presentation, we want to demonstrate that even though Section 508 promotes accessibility of electronic and information technology, it does not encourage the usability of that technology, which is equally important in order for it to be effectively used by people with disabilities. We will first demonstrate how Section 508 standards are not always an adequate solution to make a software product accessible and usable, then we will point out some of the practices used by Section 508 coordinators and software developers which ensure usability of software products. They are not the only practices that may prove successful; they are examples of the practices that have been observed at Patent and Trademark Office and Computer Science Corporation in Washington D.C., where we have been testing for Section 508 compliance. Let us look at one example of how, despite following Section 508 guidelines, the product may not be used with "comparable" access by the disabled people.

When browsing internet web sites, it is not uncommon to find a sentence such as: "For more information click here," where only the words "click here" would be made into a hyperlink. It is not against Section 508 standards to highlight and link only these two words, and no automated tool would mark it as a problem. When someone is using a screenreader and displays a list of links on the page, a link would appear on the list as "click here." This kind of link is too generic and provides no information of where it leads to. In such cases, the user has to examine surrounding text in order to understand the context in which the link "click here" is used. This does not make navigation as fast as it could have been, had the link been more descriptive and, in this case, a more meaningful phrase, rather than the words "click here", was highlighted. This example demonstrates how Section 508 web standards do not address the issue of web site usability.

A similar discrepancy can be observed between Section 508 standards for software applications and operating systems, and the usability of the software which is designed according to Section 508 software standards. For instance, it is not necessary to provide shortcut keys (also called hotkeys) in order to enable users to execute various functions within the given program. According to Section 508 software standards, as long as the user has the ability to access a particular function--sometimes by pressing the tab or the shift tab key 10 or more times--the software will be considered compliant with the standards. Keyboard access to the software's functions is important but efficiency of that access is equally as vital. While sometimes it is hard to make a product usable, or even 508 compliant, in most cases features that will make a product usable can easily be added. Sarah Abrams, a developer who works at Computer Science Corporation2 points out "if you can do it fairly simply, and if it doesn't require redesigning of an entire part of a package, , and all it's a matter of is adding something, then why not do it?" She adds that the changes that she and her team have to make are not too time-consuming and therefore she sees no reason not to implement them.

What helped Sarah to understand what needed to be changed in the software in order to make it usable was the interaction with people who are vision impaired. She said that for her it was hard to imagine what the blind people may need in order to be able to use the software. It was very useful, therefore, to listen to the advice of blind/ low vision computer users who tested the software and gave her suggestions as to how to make it more usable. "We got an understanding from them that obeying the letter of a law is one thing, enabling the software to actually be used by people with accessibility issues is sometimes something else. And our goal for all these users is to make the software as usable as possible and as easy to use," she explains.

Not all the developers think that it is an easy task to make their software usable; not all of them want to listen to the advice of disabled people either. What needs to change, according to Joyce Miller and Fred Difiore who are Section 508 coordinators at Patent and Trademark Office, is their mindset. They have to understand that it usually does not require more time or more money to make a program 508 compliant and/or usable. They point to two important factors, except for the one that it is a law and therefore has to be followed: usability of the software for the general public, and the realization that the developers themselves may benefit from Section 508 in the future.

Regarding usability for the general public Joyce points out that some developers told her that following Section 508 standards forced them to get back into good programming practices. Before Section 508 was introduced, they had taken shortcuts and the programming techniques were not as important as the final result, a product given to the end-user. She adds that if the software is made usable for the disabled community, it is also easier to use for the general public. There are a lot of disabled people among "general public" who do not officially recognize their disability. Fred Difiore points out that during his Section 508 workshops for developers, he would ask them about their various disabilities, and it turns out that a vast majority of course attendees have some kind of disability or long-term disease, ranging from physical disabilities to diabetes. This has been an effective way to prove to them that making software accessible is not related to strangers, but to themselves, and so it is in their interest to make sure that it is usable, because it will benefit them personally.

The strategy often used by the developers is to first develop a product and then to work on making it 508 compliant and/or usable. While this seems to be an acceptable approach for many, it may pose potential accessibility problems, because usability is not originally built into the product. While it is easy to make the software usable, it may mot be possible in all cases, i.e. in the case of software which uses forms library whose objects are not readily exposed to the operating system and thus prevent assistive technologies from accessing them. Such software would be difficult to make usable because other building blocks of that software would be dependant on that library. Breaking this dependence would mean the necessity to redesign the whole software. The ideal approach, therefore, would be for developers to include accessibility and usability issues into the planning phase of the software development process.

To conclude, it is important to keep in mind that while Section 508 is a set of guidelines to follow, the issue of usability should be given equal attention. Often it is not difficult to make software usable, and it is helpful to have it tested by the disabled people, since they can give suggestions as to the improvements of software usability. A successful implementation of Section 508 standards and the issue of usability can be achieved by incorporating these issues into the software development process.

1 http://www.section508.com
2 Sarah Abrams works for SOLUTRON, In.c and is currently on a contract with CSC

Go to previous article 
Go to next article 
Return to 2004 Table of Contents 
Return to Table of Proceedings

Reprinted with author(s) permission. Author(s) retain copyright.