The issues of good accessibility and usability are closely linked. Their importance has been emphasised in previous chapters of the handbook. How can these issues be best tackled and implemented in the development of a new gateway or the modification of an existing one?

User interface design

The accessibility and usability criteria of your gateway should have been drawn up after some degree of user consultation. Ideally, the user consultation will have produced a user interface design specification; The specification should contain particular information such as the gateway name, section division naming (if appropriate), structure and information architecture. Guidelines or parameters such as maximum page size (pixels and/or bytes), maximum download times, colour palette size and makeup, colour scheme and use of images will also form part of the specification. An ideal end result might be a document in the form of a checklist, against which a design can be developed and checked.

Remember that a checklist which contains too many items can be unusable in itself. Test a prototype version of your checklist to see if it is usable, before rolling it out to all developers. A design specification will probably be divided into several areas.

Usability issues

What usability issues will the gateway conform to? Guidelines here might be:

• users will be able to search from every page
• users will be able to search with one click
• help (or perhaps context-sensitive help) will be available within every page
• users will never be more than one click away from the homepage
• feedback and comment facilities will always be no more than one click away
• feedback will be provided to users on their actions (e.g. holding page while the search is being processed, guidelines on using search result pages)
• users will not need to understand technical terminology (i.e. Boolean search rules) to carry out basic tasks

Site structure and navigation

It seems obvious, but some of the key problems with Web sites arise from the naming of sub-sections and the associated navigation of them. Fortunately, information gateways have common key sections which can easily be worked into a navigation system and which are almost universally understood (subject-specific and specialised gateways may differ in this area and so may be tailored to the user community). Section names often include:

• home
• search
• browse
• help
• what's new

Accessibility issues

What accessibility criteria will the gateway conform to? Fortunately, a definitive set of accessibility guidelines already exists in the form of a W3C Recommendation: Web Content Accessibility Guidelines 1.0. It would save time and effort to adopt some or all of these official guidelines. The exact guidelines that are used may vary from gateway to gateway, as there are many recommendations and it may not be realistic to implement them all. Luckily, the guidelines have been prioritised in a way that makes it easy to see which accessibility issues have the greatest influence on potential users:

• priority 1: must do
• priority 2: should do

(see 'Disabled Accessibility: The Pragmatic Approach')

You might decide only to use items in the 'Priority 1' checklist and a selection of those from the lower priority groups, for example:

1. Provide a text equivalent for every non-text element (e.g. via 'alt', 'longdesc', or in element content). Non-text elements include: images, graphical representations of text (including symbols), image map regions, animations (e.g. animated GIFs), applets and programmatic objects, ASCII art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video.
2. Ensure that all information conveyed with colour is also available without colour, for example from context or markup.
3. Clearly identify changes in the natural language of a document's text and any text equivalents (e.g. captions).
4. Organise documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document.

The simplest way to implement and check that your gateway meets its accessibility and usability requirements is to use a simple 'checklist' during development of the interface. Developing the user interface as a series of templates, separated from the technology of the gateway, makes changing aspects of the interface much easier. As the interface develops it can be continually checked against the checklist of requirements.

When a gateway's interface is complete, it is often worth stating that the site conforms to certain guidelines (e.g. HTML 4.0, Bobby Approved, Web interoperability); however, do not do this on your most commonly accessed pages (e.g. the home page or the search page) but rather confine this information to an 'about' section or page.

Validating your gateway's accessibility

Accessibility validating using Bobby Bobby is a Web-based tool which analyses Web pages for their accessibility to people with disabilities. Bobby's analysis of accessibility is based on the World Wide Web Consortium's (W3C) Web Content Accessibility Guidelines. Bobby also analyses Web pages for compatibility with various browsers. Analysis is based on documentation from browser vendors, when this is available. Bobby automatically checks sites for compatibility with HTML 4.0. For accessibility and tag compatibility with browser specifications other than HTML 4.0, use the Advanced Options. Once your web site receives a Bobby Approved rating, you are entitled to use a Bobby Approved icon on your site. Bobby is available as a free downloadable application which allows you to check multiple local files or entire Web sites in one operation. The application runs the same page-checking code as the online version. Bobby is a very useful resource which should be used by all gateway developers and maintainers. Bobby: http://www.cast.org/bobby/

It is worth noting that Web-related technologies change, users change and information changes. However, seldom do any of these variables change at the same time. The result is that you should always be aware that the criteria for usability and accessibility are not set in stone. Along with other aspects of the gateway, these criteria should be reviewed from time to time and, if need be, adjusted to meet changes and developments. It should be noted that users rarely change as quickly as everything else around them! Caution is therefore advisable when implementing any user-side technological changes.

Adopting a Web accessibility policy makes your Web site more usable for all users.

Accessibility - the characteristics of Web content and whether or not it is accessible to people with disabilities
Usability - the degree of ease with which human beings can interact with an object, in particular a computer system
W3C - World Wide Web Consortium

Bobby, http://www.cast.org/bobby/

Disabled Accessibility: The Pragmatic Approach
http://www.useit.com/alertbox/990613.html

Jacob Nielsen's Alertbox Column
http://www.useit.com/alertbox/

List of Checkpoints for Web Content Accessibility Guidelines 1.0
http://www.w3.org/TR/WAI-WEBCONTENT/checkpoint-list.html

L. Rosenfeld & P. Morville, Information Architecture for the World Wide Web (O'Reilly, 1998).

J. M. Spool et al., Web Site Usability: A Designers Guide (Morgan Kaufmann Publishers Inc., 1999).

W3C, Web Content Accessibility Guidelines 1.0
http://www.w3.org/TR/WAI-WEBCONTENT/

Chapter author: Martin Belcher, Phil Cross

With contributions from: Jan Chipchase