2002 Conference Proceedings

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


DESIGNING AN ACCESSIBLE LIBRARY CATALOGUE FOR THE WEB

Mitake Holloman Burts
Keystone Systems, Inc.
mitake@klas.com 

James Burts
Keystone Systems, Inc
james@klas.com

In addition to workplace accessibility issues, access to information resources and community resources is an important issue. The tasks may be simpler, but when dealing with accessibility for the public, there is a much broader set of users, each with a variety of issues to accommodate. The design issues cross multiple user groups, often conflicting with each other. The best way to handle public system accessibility is to treat it as a fundamental user-interface design problem, and work on it as a ground-up solution. To tackle a user interface design several factors are important to consider - what are the goals of the product, who will the users of the product be, what assumptions can you make about them, what particular needs should be accommodated, and how can you provide feedback to the user so that they know they are being successful in their interaction with the system.

Product Goals

The library catalogue can be a powerful resource for locating and accessing information. It has several main goals:
* Inform users about what is available from the library
* Help users locate materials that they are looking for
* Allow users to obtain such materials and place requests.

In designing our library catalogue, we had three basic assumptions:
* The users would access the system through a standard web browser
* The users would want to locate and receive appropriate library materials as a result of their searches, and
* A significant number of users would use accessibility software as part of their interface (though no assumptions can be made on exactly which AT systems would be used)

General Design Issues

Before looking at specific groups of users of our system and the issues that they faced, we first looked at some basic questions that any user will constantly ask as they interact with a system.
* Where am I?
* What do I do next?
* What button do I push?
* What are my results?
* Was I successful?
* If I made a mistake, how do I recover?
It is important that designers think about how the system will answer these questions for all potential users.

Identifying User Groups

In terms of interface accommodations there were several groups that had different expectations and needs for how the screens would best look and layout. For low-vision users, especially those using screen magnification software, the answers to "where am I" and "what button do I push" are often located off the displayed portion of the screen. Thus simplicity and logic in the layout of the screen become very important. In a perfect situation everything should fit onto the screen at once - scrolling within the screen to get to a given control adds a second layer of controls that they must operate. Navigation options should be easy to locate and in a predictable spot. Further, these users frequently need control over the color scheme and font choices.

Users of screen reader software have a more linear interaction with the interface and so the order in which information is presented becomes very important. Time and time again we hear that the content of the page should appear first-don't waste the user's time by making them wade through 50 navigation links before they get to the meat of the page. So the goal in design for this group of users becomes how to present enough information so that the user is oriented and allow them to get to the results of their actions without becoming redundant.

Refreshable Braille presents a strongly textual interface with which the user can quickly move back and forth to gain context. However, the need for a logical layout that brings the user quickly to the main content of the page is a benefit.

Fully sighted users want a visually appealing interface that invites them to perform the correct action in an intuitive manner. They may expect and depend on clues such as color, changes in background, lines that divide the space, and grouping of objects. They frequently skip over navigation and header information but return to the top left when they want to go somewhere else.

In addition to considering the different levels and expectations that the various user groups will have in perceiving the interface, we also needed to consider the different levels of computer sophistication that users in any of these groups might fall under. Novice computer users tend to be timid to try things. The controls on the page need to invite them to act. They can also be frequently overwhelmed with choices. While a good help / tutorial system may be what would best suit them, they get a large amount of satisfaction and are more likely to use the system again if they can just figure it out.

Other users may have more experience and confidence with computers, but that confidence is drawn from using other systems. So it becomes important to use the controls and layouts that are consistent with experiences that the users may have encountered. This allows these users to build upon their gained knowledge and have more confidence in the system and its usefulness.

Frequently the more experienced the user the more things they want to be able to accomplish. In library catalogues, this is frequently a desire to provide more information to the computer about the search so that the results are more refined. The requests and combinations for how information needs to be presented can become very complex and users are constantly asking for more information and more features. The trick becomes how to let the user put this information into the computer in a fast and non-cumbersome manner.

Our Dilemmas and Solutions

In trying to accommodate the needs of this varied group of users we encountered several dilemmas for which we had to strike a balance in our design.

Simple Interfaces vs. Full Featured Functionality

Many of the users are new to computers and/or don't use the system all that frequently. These users want a simple interface that doesn't take much experience or brain power to use. They don't really want to have to remember a bunch of steps to get the task done. The system should lead them through the task in a friendly and helpful manner without seeming overly complex or intimidating. However, as users become more familiar with the system or transfer knowledge over from other systems they want to take advantage of more options.. How do you provide functionality without intimidating with the choices or making the activation of those choices so cumbersome that they choose not to use the options that are available?

Our solution was to provide a limited number of options as a basic feature, with a button in the middle of the form to expand the search options. This seemed especially important to users who were tabbing through the controls one at a time - something that would alert them that there were more options without forcing them to tab through all of the options. Another part of the compromise was to allow the user to set up a profile, allowing them to establish a default set of options once. These features would automatically be pulled up the next time they logged in.

Newest browser features vs. Support for older browsers

A basic assumption of the product is that the users will use a web browser that they are comfortable with to interact with the system; we cannot reasonably stipulate which browser they use. Since different browsers offer differing levels of support for various features, one of the challenges we faced was how to take advantage of the newer advancements while still supporting the older browsers. Much of this involved carefully assessing what we needed the software to do and how to best accomplish it with new methods. We also evaluated the consequences of trying to use the system without access to a given feature, and we structured the screens so that they continued to make sense even if a given feature wasn't there.

For instance, a great debate revolved around the use of JavaScript. It allows much greater interactivity on a web page without having to reload the page, however different browsers offer wildly different support for JavaScript. Since JavaScript would be an area for inconsistency, we did not feel we could use it for any critical part of the application. One place that we did find JavaScript to be beneficial was to hide some parts of the search screen, thus presenting a 'Simple' screen. A button on the screen would re-display the hidden fields, giving a more advanced search. If there was a problem with JavaScript on the user's browser (or if the user simply had it turned off), the screen would simply display all the options without hiding a particular section.

What comes first on the page? - Navigation vs. Content

Visual users expect to see the navigation tools to be located at the top-left section of the screen, and the body of the page to follow after these navigation links. Users of screen readers hate having to wade through all the navigation, and want to get to the meat of the content quickly. This apparent conflict is solved by using cascading style sheets, which allows the content of the page to be separated from the format. This in turn allows the user's technology to present the information according to their preferences. By using cascading style sheets, the body of the document does indeed appear first in the html markup, while the navigation menu is displayed in the top-left for the visual-user. Once again the trick was to make sure that even browsers that do not support CSS would display the information reasonably so that user of those browsers would be alerted to their navigation options.

How will it look? - Corporate Image vs. User Preferences

Another aspect to grapple with is that no matter how carefully you craft the look and layout of your screens the design may not work best in that layout for all of your users. While your corporate image may stipulate medium blue text in various sizes and weights of Veranda, your user may find reading text in anything but 16pt Arial bold in yellow on a black background to be very tiring and difficult. You may also identify different user groups for whom you want to optimize the layout of your page to meet their needs. By using cascading style sheets we were able to meet the requirements for a visually appealing layout while keeping the structure intact for users who chose not to use that layout.

Conclusion

Designing information systems for a broad range of users can be a challenge. But by carefully analyzing the needs of the various groups of users, and concentrating on presenting the structure within a flexible layout, a balance can be struck to meet the needs of a wide variety of users.

Company Information

Keystone Systems has been designing and building library automation systems since 1983. One of our major markets encompasses libraries established specifically to serve patrons unable to manage printed media due to visual or physical impairment. More information about Keystone Systems can be found at http://www.klas.com/.


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


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