World Wide Web Browser Guidelines

(Updated 2/13/97)

Compiled by:
Jon Gunderson, Ph.D., APT
Chair, Browser User Interface Guideline Development Group
W3C Web Accessibility Initiative

Division of Rehabilitation - Education Services
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL 61820
Phone: (217) 244-5870
E-mail: jongund@uiuc.edu



This is the first draft of a living document prepared as part of the W3C Web Accessibility Initative.  The author and W3C encourage comments on this document.  Please send all comments to Jon Gunderson at jongund@uiuc.edu

Table of Contents

I. Introduction to WWW Browser Accessibility

II. Browser Accessibility Checklist Description

A. Presentation Adjustment

Override Font and Color Specification
CSS Override and User Specification
Alternative Representations of Information
Alternative Views of Information
Browser Menus and Dialog Boxes

B. Navigation and Control

Navigation Commands with Mouse Equivalents
Navigation Commands with out Mouse Equivalents
List of Important Navigation Commands
Navigation Commands from the Keyboard
Navigation Commands from the Menu
Navigation Commands on the Toolbar
Scripting Language Event Emulation

C. Orientation Support

Document Summary Information
Document Structural Information
DYNAMIC HTML Event Notification
Maintenance of Orientation Between Documents and DHTML Events

D. Visibility of Accessibility Features

Menu Options
Toolbar Options
Accessibility Dialog Box
Documentation

III. Guidelines Checklist

IV. Test Pages for Accessibility


I. Introduction to WWW Browser Accessibility

WWW browsers are the windows to the universe of information available on the World Wide Web (WWW). For information on the WWW to available to all users, browsers need features that permit a wide range of user capabilities to see through these windows with equal clarity and control. Browser features needed by persons with disabilities or older persons with reduced capabilities often find general acceptance by able-bodied users who may be temporarily impaired, or are using a technology that impairs them (laptop and other mobile computer technology). The guidelines presented in this document outline features that provides a more flexible user interface to allow users (not just those with impairments) to have a much greater choice in choosing their style of interaction with browser.

The flexibility and acceptance comes from:

People are created with all types of capabilities and handicaps, and as people age typically their capabilities are reduced and their handicaps increase. As people get older they often loose strength or range of motion, or their visual acuity and field of view decreases. Some people are just born with reduced capabilities, just think of how many people wear glasses! Many people can adapt to the way technology is designed and therefore can benefit from the technology. But for some people their handicaps may become a disability if they cannot adapt the technology to their needs. In this case technology needs to be more flexible to allow users to adjust the technology or use assistive technologies to make the technology more usable to them. The goal is of these guidelines is to provide funcational and meaningful access to browser technology for the largest number of users as possible.

II. Browser Accessibility Checklist Description

To improve the usability of browser technology to people with disabilities four main areas of browser features must be considered. The ability of users to control how information is presented is very important. For persons with print disabilities the ability to control the color of the foreground and background, size and shape of fonts, and the ability to adjust spatial formatting is critical for them to be able to view WWW documents. The primary interaction technique used to interact with WWW pages and browser technology is the mouse. Many persons with disabilities cannot use a mouse for various reasons and therefore need alternatives to the mouse for navigation of the WWW and access to browser features. For people with print disabilities (vision or cognitive) the ability to orient themselves to where they are in a WWW site or page can be difficult. Simple identification of major headers and other structural elements of a document are a major problem for persons with print disabilities. For print disabilities the combination of navigation and orientation commands has a tremendous impact on their ability to read and understand information. The visibility of accessibility features is important, since many accessibility options will not be familiar options to able-bodied users (at least initially). Many users with disabilities rely on able-bodied peers for assistance in helping them configure and use browser technology. Accessibility options and configuration information needs to be easy to find and adjust so that persons with disabilities can take advantage of the usability features.

A. Presentation Adjustment

Override Font and Color Specification

Users with print disabilities need to be able to specify the font size, face and the colors used for the background, text presentation and HTML graphical elements (list bullets, horizontal rule, table lines). The user needs to be able to turn off HTML author defined colors and fonts and have the ability to specify their own foreground and background colors, and font characteristics. This includes the colors used for visited and un-visited links. Users need to control whether author defined background images are rendered. The browser should also pass the specified colors and fonts on to Java or other OBJECT tag controls (Active-X) that appear on WWW pages. These OBJECTs should inherit the colors and fonts for their own interaction with the user. This provides the user with a consistent user interface and a one time adjustment to set rendering characteristics for all WWW documents.

CSS Override and User Specification

Users with print disabilities need the ability to override Cascading Style Sheets (CSS) used by authors for page layout and presentation control. Users need to be able to turn off all author level specifications whether they are external, embedded or in-line. Users need to be able to specify their own CSS style sheets to meet their own rendering needs. User specified style sheets will tend to be general and therefore author sub-classed objects in the WWW document need to take their inheritance from only the users style sheet. In most cases this will eliminate spatial formatting like columnar text, so that the document will be presented sequentially. The sequential presentation reduces the demands on users with print impairments to identify and manipulate horizontal scroll bars to identify and read information.

Alternative Representations of Information

Users with sensory (hearing and vision) impairments will want to have alternatives to the representations of information they cannot use effectively. For persons with visual impairments instead of presenting images the user would want to present the ALT text of an IMAGE tag. The ALT text should be fully rendered. Some browser technology cuts off ALT text when the ALT text does not fit into the space originally allocated for rendering of the image. The user should also receive the ALT text whether the image is in the browser’s cache. Some browsers when images are turned off still render the images that remain in the browser document cache. In addition to the ALT text there is now a LONGDESC attribute (also associated with FRAME and TABLE tags) that is a link to a longer description. The browser needs to have an option to make this link available to the user. One proposal is that it should be rendered as a D link after the image if the option is turned on. If the IMAGE is also a link and no ALT text is present, but there is a NAME attribute defined the name attribute should be rendered instead of the ALT attribute. If there is both a NAME and an ALT attribute the NAME attribute should be used first (proposed solution).

Alternative Views of Information

One of the problems, especially for users with print impairments, is to get information about the overall content of a WWW document. Able-bodies users can visually scan a document to see important organizational and topical information associated with the document. Users with visual impairments do have this capability with their vision. The browser can assist in this function by providing alternative views of documents that provide an outline of the contents of the document. For example having a view that shows only the outline of the headers and other major constructs. Some elements like a table structure can be summarized in the outline view as a "Table with X rows by Y columns of numeric information". If there was a summary attribute (proposed HTML spec) for the table it could be used in the summary description of the table. Users with visual impairments need to be able to switch between the alternative views and the standard view with maintenance of their relative position in each view. This feature would allow users to easily switch back and forth between the views to find topics and then get more detailed information.

Browser Menus and Dialog Boxes

There are features with in browsers that are not directly related to the rendering and viewing of WWW documents. These include functions for configuring browser options and services like history lists and bookmarks. These functions also need to be accessible to person with disabilities. The accessibility of these types of browser functions is often dependent on the accessibility of the operating system and the ability of third party assistive technologies to adapt the system access features to the needs of persons with disabilities. This dependence is based on the browser using operating system features and APIs for implementing common controls, dialog boxes and menus. But there are things that developers can do make these features more accessible. The inclusion of keyboard commands to navigate menu items, dialog boxes and listing controls can be used to improve accessibility in most operating systems. Many operating systems do not require the developer to include keyboard navigation, so to the extent that the developer can include them they should. Developers can take an extra step in providing additional functionality to improve operating system accessible features. For example in the Microsoft Windows operating system the browser developer could use any font or system color changes in the rendering browser dialog boxes, since changing system font size in Windows doesn’t automatically change the fonts used for dialog boxes. In this case the users maybe able to get to a dialog box, but not be able to use it since the fonts are different than what they set the system fonts to be. The biggest issue is designing the dialog boxes to be scalable to use different size fonts. This will require more careful definition of dialog box functions, so if fonts are enlarged the dialog box controls would scale to the size available for the dialog box without making some of the controls disappear or have controls overlap each other.

B. Navigation and Control

Navigation and control of WWW pages is the most important issue for many types of print disabilities that require users to use speech or dynamic Braille displays. Navigation and control is strongly related to orientation, since a user needs to know where they are and what control options are available for them to make intelligent decisions about what they want to do next. Navigation is getting more complex with the introduction of scripting languages like JavaScript and VBScript that is used in conjunction with Dynamic HTML (DHTML) to create WWW documents that can respond to user commands. Scripting languages and DHTML provide the capability to make any HTML element respond to user events. Events can include user inputs from the mouse or the keyboard. Most of the events authors will probably use will be mouse movements and mouse button events, since this is most compatible with the mouse interface that is used to select links. This is a problem for persons who cannot use the mouse or people with print impairments who cannot see the mouse pointer or the results of the event. Simply moving the mouse over an HTML element can be an event, so there are a lot of subtle ways to use this technology.
Three important questions to ask are:
  1. How will the person know the event exists?
  2. How do they emulate or simulate the event?
  3. How do they know how the event changed the document?
These are difficult problems that will be dependent on both the developers of WWW browsers, operating system access features and third party assistive technology providers.

Navigation Commands with Mouse Equivalents

There are two main types of navigation commands needed for WWW browsers. The first types of navigation commands have mouse pointing equivalents for selecting links and manipulating form controls. Examples of this type of navigation commands include changing the selection focus between hypertext links, selecting hypertext links, and to move between form based controls. These types of navigation commands all have mouse pointing equivalents and the mouse pointing equivalents are generally more popular for able-bodied users in GUI environments. In this approach links are treated similar to a button on a form. These types of navigation controls are found in keyboard commands that are familiar to Lynx users and available on later versions of Netscape Navigator and Microsoft Internet Explorer. Keyboard based commands provide the same type of function as pointing and clicking with the mouse to select links or form control on a WWW page. The keyboard commands available in some browsers though could just as easily be menu commands or commands from a toolbar. Keyboard, menu and toolbar options for issuing commands are useful to people with different types of capabilities.
The current command features available on GUI based browsers and lynx only allow for sequential access to links by using the TAB or ARROW keys to move the focus one link at a time through the document. This is a problem if a page has a large number of links and requires the user to sequentially move through each link to get to the one the user wants to select. Ideally there needs to be additional navigation commands for direct selection of links that would dramatically improve the time to complete the link selection task in pages with a large number of links. There are a number of ways to accomplish this task. One way is to have a command that would provide a list box of all links on the page. The user can just start typing in the name of the link to quickly move the focus to the link. The link list dialog box could be a command available through menus, toolbar and directly from keyboard.

Navigation Commands with out Mouse Equivalents

Other types of navigation commands do not have mouse based equivalents and would be primarily to assist in the navigation/orientation of document elements and the keyboard emulation of scripting language mouse events. For these commands to have any use they need to tell third party assistive technology what is the current focus element. Navigation commands can then be used to move this pseudo focus around the screen. There are two ways current assistive technology can track this pseudo focus provided by the browser. One way is to highlight the focus element when the use navigates to the element. Most third party assistive technology for people with visual impairments can track highlighted text. Most popular browser technology like Netscape Navigator, Microsoft Explorer, lynx and pwWebSpeak already have the capability to highlight elements. The highlight feature is already built-in and is commonly used for cut, copy and paste operations from the browser to other programs. The status bar could be used to give additional information about the type of element the user has moved to, and if the element has additional characteristics such as if the element is a link or has a DHTML event associated with it. The other way to indicate focus to third party assistive technology is use the inset caret typically found in word processing programs and in text edit controls. The insert caret is less likely to be used since it has no equivalent in any current browser technology.
Navigation is a difficult issue, especially with new more interactive WWW page technologies, but there are many navigation features that can improve accessibility. Features can be added for navigation and control of WWW documents that can be selected from keyboard, menus and toolbars.

List of Important Navigation Commands

Link (Anchor) Headers List Items Forms Tables Frames DHTML

Navigation Commands from the Keyboard

The keyboard based navigation commands provide the most direct way to navigate through a document, but are also the least visible. People can not intuitively determine what are keyboard navigation commands, and either must determine them by exploration or through some type of documentation on what are the keyboard commands. Infrequent users of browser technology or navigation commands that are used less frequently will be difficult for most users to remember. Keyboard commands should have logical key mapping to make them easier to remember and documentation should be available in help files. The visibility of keyboard features can be enhanced with the parallel availability of the navigation commands in menus and the toolbar (see next sections).

Navigation Commands from the Menu

Menu based commands are much more visible to users than commands that are only available through the keyboard. Most operating systems can display keyboard equivalents next to the menu label so that both users with and without disabilities can be aware of availability of keyboard commands. Menu based navigation commands can be a configuration option for browser developers that are concerned about the utility of the menu based navigation commands for general users. Menus can also be used to display orientation and summary information about the document. For example the Headers menu option could also be updated with the number of headers in the document. So the menu item could read "23 Headers" for a document with 23 header elements or "10 Headers" for a document with 10 header elements.

Navigation Commands on the Toolbar

Toolbar based navigation commands need to be configured to meet an individuals needs since toolbar real-estate is typically very valuable. Toolbar functions would allow users who still want to use the mouse to navigate through the document using a small area (toolbar) to control the browser. For readers with an assistive technology background the toolbar could be considered a type of custom keyboard for control of the browser. The user could use toolbar buttons to change the view of the document or move to and select links (or any other function listed, although it would be difficult to have all the functions available at one time on the space available in the toolbar). The toolbar is useful for people with impaired range of motion since they can use a relatively small area to point to browser commands.

Scripting Language Event Emulation

Scripting languages and DHTML allow any HTML element or document to respond to mouse and keyboard events. Some of the events are bound to individual HTML elements within the document and others are global to the entire document. The author (programmer?) determines the extent of the event action. The user needs to be aware that scripts are present that will handle certain events and what elements of the document have been bound to events. From a navigation and control perspective the user needs to emulate the events that the page is designed to respond to if the user cannot generate the event (i.e. mouse events). Mouse events will probably be the most popular type of event that authors will use since most users are familiar with using the mouse pointer to interact with WWW pages.

C. Orientation Support

For users with print impairments orientation to the content of WWW documents is a major issue. Since many print impaired users can only "view" a small portion of the document at a time due to screen magnification, reduced visual field of the user or the are using speech or Braille displays. Therefore it more difficult if not impossible for some people with print disabilities to view the information on the computer display. In addition to the smaller view, many elements in the document are graphic so the user cannot adjust the rendering of the image to their visual capabilities. In general information that able-bodied users can determine from viewing the screen is not available to persons with print impairments. Most elements within a WWW document are identified through their font characteristics. For example headers are usually bold and larger font size than standard paragraph text. Header level 1 is usually a larger size font than header level 2 elements. Person with print impairments cannot view these font characteristics of headers easily to pick out the major topics in a WWW document.
Some of the central questions related to orientation for people with print impairments are: Able body users can use the scroll bars and the visual formatting of the page to get this type of information. Users with print impairments need additional capabilities to be able easily extract this type of information from the page with a minimal amount of specialized knowledge and time demands.

Document Summary Information

Document summary information can be provided in the status line include the following information: The summary information should be presented in a format that reads easily like a sentence.

For example:
"Document is 2635 bytes long with 22 headers, 14 links, 1 table and 5 form controls".

An orientation command (keyboard and/or menu) should be available to update the status line with the current orientation information, since information on the status line is transient and other information can over write the status line at any time. Most third party assistive technology supports direct access to status line information.
Another way to present the summary information is in combination with menu based navigation controls. The menu labels can change to reflect the number of elements of that type. For example a WWW document with 16 headers would have a menu item that had a label of "23 Headers". This allows the user to just use the menu to see how many header elements are in the document. The menu commands available can include previous and next header navigation commands, a listing of the first 9 headers that can be moved to directly, and a menu option to bring up a list box element with all the headers.
Another way to implement document summary information is through a message box. A dialog box would provide similar information as the status bar. Since there is more space available in the message box could provide a more detailed summary of information. The draw back of the message box is that the user needs to cancel the box to continue to view the document.

Document Structural Information

One problem for users with print impairments is getting an overview of the structure of the document. This is a step beyond the summary information to allow the user to easily review the header labels, relationships between elements (tables, lists, headers, anchors, forms). One way to provide this information is through an alternative view of the WWW document. The alternative would be similar to an outline of a book. For example an outline view would list only headers, ALT tags from images and ISMAPs, the presence of tables and table size, the presence of forms and types of form controls, elements with Scripting Events, Java/Active-X objects, and standard links. The browser would allow the user to switch between the summary view and the standard view while maintaining the relative position in each view. So when the user encounters a topic of interest in the outline view they can switch views to the full document and the "focus" in the full document would correspond to the element in the outline view. If the user switches back to the outline view the "focus" will be at the nearest element in the outline. This type of feature serves both as orientation and navigation a navigation feature.

Dynamic HTML Event Notification

The issue of Dynamic HTML is a difficult issue since authors have a wide range of options in the use of scripts. Some scripts probably do little to enhance the document and other documents the scripts are a central part of making the document more usable. In either instance the browser needs to support users with disabilities to activate the events required by the script, and orient the user to the results of event activation. Scripting languages should support the accessibility APIs available for some operating systems. The accessibility API provides a way for assistive technology to gain access to screen and other information that is not normally available through the standard operating system. Assistive technology would be able to identify the objects on screen for the user to view the changes and provide some help in orienting the user to the types of changes that the event created.

Maintenance of Orientation Between Documents and DHTML Events

One major problem with screen readers accessing browsers like Netscape or Explorer is the inability of the user to maintain there "current" location in a document. If they follow a link and try to come back to a previous document, they essentially start over in their orientation to the document. This is also a problem when scripting languages create and close windows. As each window is opened and closed the user must move their review cursor to the new window, thus losing their place in the last window. The ability of the browser to support the user in maintaining their location as they move between documents or scripting event windows improves usability. This requires the browser to create and remember some type of place holder where the user last had their "focus" (see navigation section) that is easy for assistive technology like screen readers to detect and track. This could be maintaining the last highlighted text that was used for navigation.

D. Visibility of Accessibility Features

Building accessibility features into browser technology will not be very useful unless users who can benefit from the features know that they are available. Many of the features will be useful to people without disabilities, so they should not be labeled as disability only features. Therefore the visibility of the features is very important to all users. The less specialized knowledge that the user with a disability needs and the more the accessibility features find general acceptance among the able bodied user population the more people with disabilities will know and benefit about the features. Many people with disabilities will not have skilled rehabilitation professionals with specialized knowledge about access techniques available to them to help them learn about specialized access technologies. They will most often rely on their own skills and the skills of their peers in helping them understand the browser/assistive technology features that they can use to access browser technology. There are many ways to make browser accessibility features visible to users.

These including the features in:

Menu Options

By having an option to place navigation and orientation information in menus the information is highly visible, especially to able-bodied peers who may be helping the person with a disability. Menus are dynamic and can be updated based on new documents. Direct keyboard equivalents for the menu function can be displayed next to the menu label in some operating systems, providing a highly visible way for people to find them.

Toolbar Options

The ability to have the toolbar functions configure by the user allows the user to essentially create their own custom keyboard interface to the browser. The user should be able to select the navigation commands they wish to place on the toolbar, given the constraints of the toolbar real-estate. The size and colors of the icons on the toolbar should also be adjustable by the user. This allow persons with visual impairments to still benefit from toolbar options.

Accessibility Dialog Box

The inclusion of an accessibility dialog box provides one place for a user with a disability to identify and adjust all of the features of the browser that have been identified as useful for people with disabilities (whether or not the feature was designed specifically for accessibility). It should be a menu option or a prominent part of the standard user configuration dialog box that is clearly labeled with the term "Disability Access Options". The dialog box will provide the user the ability to change fonts, colors, style sheets and other options related to accessibility. The ability to preview the changes the user is making is also important to make the adjustment process easier for the user.

Documentation

There are several types of documentation that improve the visibility of the accessibility. The most important is on-line documentation that identifies the keyboard navigation commands and other accessibility features. The table of content needs to have a section that is clearly labeled disability access features. This section identifies all the features of the browser that are useful to people with disabilities. The on-line index needs to contain key words like disability, keyboard commands, accessibility, font size, colors, handicap and other words that may be used by users with disabilities to find out about access features. In addition to the on-line documentation and print materials should have a section in the table of contents and index that identify the disability access features and how to use them with different disabilities. Print materials should also be made available in alternative formats including large print, Braille and electronic text at the request of the user.

III. Guidelines Checklist

Link to draft of browser user interface checklist

IV. Test Pages for Browser Accessibility Features

******** Under construction *********