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
Override Font and Color Specification
CSS Override and User Specification
Alternative Representations
of Information
Alternative Views of Information
Browser Menus and Dialog Boxes
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
Document Summary Information
Document Structural Information
DYNAMIC HTML Event Notification
Maintenance
of Orientation Between Documents and DHTML Events
Menu Options
Toolbar Options
Accessibility Dialog Box
Documentation
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:
-
Providing users with greater control over the way documents are rendered
on the screen (font size and type, foreground and background colors, spatial
formatting…)
-
Providing additional keyboard control for navigation between and within
WWW documents.
-
Providing additional ways to summarize the document through alternative
views of document information and through additional status line information.
-
Providing orientation information to users about their location and the
content of information in a document.
-
Improving the visibility of new interaction features, so that all users
can benefit from their availability.
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:
-
How will the person know the event exists?
-
How do they emulate or simulate the event?
-
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)
-
Move to previous link
-
Move to next link
-
Move to link from list
-
Select link
Headers
-
Move to previous header
-
Move to next header
-
Move to header from list
List Items
-
Move to previous list item
-
Move to next list item
-
Move to list item from list
Forms
-
Move to previous control
-
Move to next control
-
Move to control from list
-
Change state of control (control dependent)
Tables
-
Move to previous table
-
Move to next table
-
Move to table from list
-
Move to next column
-
Move to next row
-
Present table row header on status line
-
Present table column header on status line
-
Find in table
Frames
-
Move focus to next frame
-
Move focus to next frame
DHTML
-
Move to previous element with DTHML event
-
Move to next element with DTHML event
-
Activate event
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:
-
How does user know how large the document is?
-
How does the user know about the content of the page (headers, tables,
frames, links…)?
-
How does the user know find the major topics of the page?
-
Where is the user in the document?
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:
-
Size of document in bytes
-
Number of headers
-
Number of anchors
-
Number of frames
-
Number of tables
-
Number of form items
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
-
Toolbar Options
-
Accessibility Dialog Box
-
Documentation
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 *********