Web technologies are forever forging ahead. Each day brings new gadgetry and wizardry to
the browsing experience, opening up reams of electronic information and entertainment at an
accelerating pace for those with the technical where-with-all to access it. Yet, many Web
citizens are not in a postion to reap the advantages because of both technical deficiencies
and physical disabilities for experiencing the content as originally conceived and presented.
Web accessibility issues pertain to page design for users who
- may not be able to see, hear, move, or may not be able to process some types of information
easily or at all.
- may have difficulty reading or comprehending text.
- may not have or be able to use a keyboard or mouse.
- may have a text-only screen, a small screen, or a slow Internet connection.
- may not speak or understand fluently the language in which the document is written.
- may be in a situation where their eyes, ears, or hands are busy or interfered with (e.g.,
driving to work, working in a loud environment, etc.).
- may have an early version of a browser, a different browser entirely, a voice browser, or a
different operating system.
Web developers should consider these situations during page design. Granted, there may be
situations where it is impractical or unwise to compromise a design for accessibility purposes.
A Web site that features inaccessible technologies need not apologize for lack of presentation
alternatives if none are truly available to duplicate the experience in other ways. There are also
cost and marketing considerations. It may be resource-prohibitive to create a parallel site for a
small population of users and a competitive disadvantage to delay available until it is completed.
Still, the search for presentation alternatives should continue. In some cases there are
technical solutions to accessibility problems. In other cases there are page coding remedies.
Assistive technologies provide mechanical and software means to overcome physical or cognitive
disabilities. Examples include
- Eye movement mouse. A camera mounted on the computer monitor focuses on the user's eye.
The mouse cursor is positioned where the user is looking and mouse clicks are performed with an eye
- Foot control mouse. A foot control mouse uses two pedals, one for cursor movement and the
other for mouse clicks.
- Head tracking mouse. A signal from atop the computer monitor tracks a reflector placed on
the user's head or eyeglasses. Movement of the user's head controls the direction and distance of
- Touch sensitive keyboard/mouse. The keyboard works with the slightest touch of a hand-held
wand or mouth stick requiring no force of pressure. The mouse function works like a standard mouse but
requires no hand dexterity.
- Mouth controlled joy stick. A pointer controls cursor movement on the screen; "sipping" or
"puffing" on the mouth stick simulates mouse clicking.
- Touch screen. Screen overlays are sensitive to finger and wand touch to track cursor movement
and activate mouse clicks.
- Screen and text readers. Software reads aloud or converts to brail information appearing on the
monitor screen or speaks text entered through the keyboard or appearing in documents such as text files,
email messages, or word processing documents.
- Screen magnification. Software enlarges screen display to as high as 16x magnification.
- Sign language communicator. Converts text or speech to video sign language or
- Speech recognition. Devices and software to control computers through spoken words and
phrases; assistive writing by coverting speech into text without use of pencil and paper.
- Cognitive planners/reminders. Assist users in accessing and remembering
information; provides on screen cueing and planning assistance for people with memory and attention
disorders, keeping them on schedule with graphic displays, selection menus, and personalized verbal and
Most of these solutions take place on the end-user side. They must be purchased and installed
on individual computers. The Web developer has little or no impact on whether Web content may be
accessible by these methods. The developer can, however, assist many of these assistive technologies
by following compatible site design and coding practices when creating Web pages.
W3C Accessibility Guidelines
The World Wide Web Consortium (W3C) produces a set of Web Content Accessibility Guidelines
(http://www.w3.org/TR/WCAG10/) on how to
make Web content accessible to people with disabilities. By following these guidelines content
developers can create pages that remain accessible despite the constraints of physical, sensory, and
cognitive disabilities. Some general keys to designing such pages include:
- Separate structure from presentation. Recognize that the information content of a Web page
is different from, and usually separate from, its visual appearance.
- Provide text alternatives to audio and video content. Text can be rendered in ways that are
available to almost all browsing devices and accessible to almost all users.
- Create documents that do not rely on one type of hardware. Pages should be usable by people without
mice, with small screens, low resolution screens, black and white screens, no screens, and with only
voice or text output.
The W3C provides fourteen guidelines under three priority levels commensurate with their impact on
accessibility. Some of these guidelines refer to technologies or techniques that are not covered in
Priority 1 guidelines must be satisfied; otherwise, one or more groups will find
it impossible to access information in the document.
Priority 2 guidelines should be satisfied; otherwise, one or more groups will find
it difficult to access information in the document.
Priority 3 guidelines may be satisfied; otherwise, one or more groups will find it somewhat
difficult to access information in the document.
The following discussion summarizes these guidelines. You should visit the W3C accessibility
site for complete details.
Guideline 1. Provide equivalent alternatives to auditory and visual
This guideline emphasizes the importance of providing text equivalents of non-text content (images,
pre-recorded audio, video). The power of text equivalents lies in their capacity to be rendered in
ways that are accessible to people from various disability groups using a variety of technologies.
Text can be readily output to speech synthesizers and braille displays, and can be presented visually
in a variety of sizes on computer displays and paper.
Provide a text equivalent for every non-text element. For example, use
alt text for the
<img> tag. For complex
content where alt text does not provide a complete text
equivalent, provide a link to a text description. For image maps use the alt
<area> tags. [Priority 1]
Until user agents can automatically read aloud the text equivalent of a visual track, provide
an auditory description of the important information of the visual track of a multimedia presentation.
For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent
alternatives (e.g., captions or auditory descriptions of the visual track) with the
presentation. [Priority 1]
Until user agents render text equivalents for image map links, provide redundant
text links for each active region of a client-side image map. [Priority 3]
Guideline 2. Don't rely on color alone.
Ensure that text and graphics are understandable when viewed without color.
If color alone is used to convey information, people who cannot differentiate between certain colors
and users with devices that have non-color or non-visual displays will not receive the information.
When foreground and background colors are too close to the same hue, they may not provide sufficient
contrast when viewed using monochrome displays or by people with different types of color deficits.
Ensure that all information conveyed with color is also available without color, for example
from text context or markup. [Priority 1]
Ensure that foreground and background color combinations provide sufficient contrast when
viewed by someone having color deficits or when viewed on a black and white screen. [Priority 2].
Guideline 3. Use markup and style sheets properly.
Mark up documents with the proper and intended use of XHTML elements, that is, as information
structuring devices rather than styling techniques. Control presentation with
style sheets rather than with attributes. Using markup improperly hinders accessibility.
When an appropriate markup language exists, use markup rather than images to convey
information. Avoid using images to represent text -- use text and style sheets instead. [Priority 2]
Create documents that validate to published XHTML standards. [Priority 2]
Use style sheets rather than deprecated attributes to control layout and presentation.
Use relative measurement units (percentages) rather than absolute units (pixels) in markup
attribute values and style sheet property values. [Priority 2]
Use header elements to convey document structure, not for style effects.
For example, use H2 to indicate a subsection of H1, not because of size differences in the fonts.
Nest OL, UL, and DL list items properly. [Priority 2]
Guideline 4. Clarify natural language usage
Use markup that facilitates pronunciation or interpretation of abbreviated or foreign text.
When content developers code natural language in a document, speech synthesizers and
braille devices can automatically switch to the new language, making the document more accessible to
multilingual users. Also, natural language markup allows search engines to
find key words and identify documents in a desired language.
Clearly identify changes in the natural language of a document's text and captions. For example,
use "xml:lang" in page prologs. [Priority 1]
Specify the expansion of each abbreviation or acronym in a document where it first occurs.
Guideline 5. Create tables that transform gracefully.
Ensure that tables have necessary markup to be transformed by accessible browsers and other user
agents. Tables should be used to mark up truly tabular information ("data tables") and
should be avoided to lay out pages ("layout tables"). Tables for any use present special
problems to users of screen readers.
For data tables, identify row and column headers. Use
to identify data cells and
<th> to identify headers. [Priority 1]
For data tables that have two or more logical levels of row or column headers, use markup to
associate data cells and header cells. Use
<tfoot> to group rows and use
<colgroup> to group columns.
Do not use tables for layout unless the table makes sense when presented in a linear (across
rows and down columns) fashion. Otherwise, provide an alternative presentation.
If a table is used for layout, do not use any structural markup for the purpose of visual
formatting -- do not use the
<th> element to cause the content of
a (non-table header) cell to be displayed centered and in bold. [Priority 2]
Provide text summaries for tables where practical. [Priority 3]
Guideline 6. Ensure that pages featuring new technologies transform gracefully.
Ensure that pages are accessible even when newer technologies are not supported or are turned off.
Although content developers are encouraged to use new technologies, they should know how to make their
pages still work with older browsers and people who choose to turn off features.
Organize 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.
Ensure that equivalents for dynamic content are updated when the dynamic content changes.
Ensure that pages are usable when scripts, applets, or other programmatic objects are turned
off or not supported. If this is not possible, provide equivalent information on an alternative
accessible page. [Priority 1]
Ensure that dynamic content is accessible or provide an alternative presentation or page.
Guideline 7. Ensure user control of time-sensitive content changes.
Ensure that moving, blinking, scrolling, or auto-updating objects or pages may be paused or stopped.
Some people with cognitive or visual disabilities are unable to read moving text quickly enough or at
all. Movement can also cause such a distraction that the rest of the page becomes unreadable for people
with cognitive disabilities. Screen readers are unable to read moving text. People with physical
disabilities might not be able to move quickly or accurately enough to interact with moving objects.
Until user agents allow users to control flickering, avoid causing the screen to flicker.
Until user agents allow users to control blinking, avoid causing content to blink [Priority 2]
Until user agents allow users to freeze moving content, avoid movement in pages. [Priority 2]
Until user agents provide the ability to stop the refresh, do not create periodically
auto-refreshing pages. [Priority 2]
Until user agents provide the ability to stop auto-redirect, do not use markup to redirect
pages automatically. [Priority 2]
Guideline 8. Ensure direct accessibility of embedded user interfaces.
Ensure that the user interface follows principles of accessible design: device-independent access
to functionality, keyboard operability, self-voicing, etc. When an embedded object has its "own
interface", the interface -- like the interface to the browser itself -- must be accessible. If the
interface of the embedded object cannot be made accessible, an alternative accessible solution must
Guideline 9. Design for device-independence.
Use features that enable activation of page elements via a variety of input devices.
Device-independent access means that the user may interact with the user agent or document with
a preferred input (or output) device -- mouse, keyboard, voice, head wand, or other.
Provide client-side image maps instead of server-side image maps except where the regions
cannot be defined with an available geometric shape. [Priority 1]
Ensure that any element that has its own interface can be operated in a device-independent manner.
For scripts, specify logical event handlers rather than device-dependent event handlers.
Create a logical tab order through links, form controls, and objects. [Priority 3]
Provide keyboard shortcuts to important links, form controls, and groups of form controls.
Guideline 10. Use interim solutions.
Use interim accessibility solutions so that assistive technologies and older browsers will operate
correctly. For example, changing the current window or popping up new windows can be very
disorienting to users who cannot see that this has happened.
Note. The following checkpoints apply until user agents (including assistive technologies) address
these issues. These checkpoints are classified as "interim", meaning that the Web Content
Guidelines Working Group considers them to be valid and necessary to Web accessibility as
of the publication of this document. However, the Working Group does not expect these checkpoints
to be necessary in the future, once Web technologies have incorporated anticipated features or
Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to
appear and do not change the current window without informing the user. [Priority 2]
Until user agents support explicit associations between labels and form controls, for all form
controls with implicitly associated labels, ensure that the label is properly positioned immediately
precedits its control on the same line. [Priority 2]
Until user agents (including assistive technologies) render side-by-side text correctly, provide a
linear text alternative (on the current page or some other) for all tables that lay out text in
parallel, word-wrapped columns. [Priority 3]
Until user agents handle empty controls correctly, include default, place-holding characters in edit
boxes and text areas. [Priority 3]
Until user agents (including assistive technologies) render adjacent links distinctly, include
non-link, printable characters (surrounded by spaces) between adjacent links. [Priority 3]
Guideline 11. Use W3C technologies and guidelines.
Use W3C technologies and follow accessibility guidelines. Where it is not possible to use a W3C
technology, or doing so results in material that does not transform gracefully, provide an alternative
version of the content that is accessible.
Use W3C technologies when they are available and appropriate for a task and use the latest
versions when supported. [Priority 2]
Avoid deprecated features of W3C technologies. [Priority 2]
Provide information so that users may receive documents according to their preferences (e.g.,
language, content type, etc.) [Priority 3]
If, after best efforts, you cannot create an accessible page, provide a link to an alternative
page that uses W3C technologies, is accessible, has equivalent information (or functionality), and
is updated as often as the inaccessible (original) page. [Priority 1]
Guideline 12. Provide context and orientation information.
Provide context and orientation information to help users understand complex pages or elements.
Grouping elements and providing contextual information about the relationships between elements can
be useful for all users. Complex relationships between parts of a page may be difficult for people
with cognitive disabilities and people with visual disabilities to interpret.
Title each frame to facilitate frame identification and navigation. [Priority 1]
Describe the purpose of frames and how frames relate to each other if it is not obvious
by frame titles alone. [Priority 2]
Divide large blocks of information into more manageable groups where natural and
appropriate. [Priority 2]
Associate labels explicitly with their controls. [Priority 2]
Guideline 13. Provide clear navigation mechanisms.
Provide clear and consistent navigation mechanisms -- orientation information, navigation bars,
a site map, etc. -- to increase the likelihood that a person will find what they are looking for at
a site. Clear and consistent navigation mechanisms are important to people with cognitive disabilities
or blindness, and benefit all users.
Clearly identify the target of each link. Link text should be meaningful enough to make
sense when read out of context -- either on its own or as part of a sequence of links. Link text
should also be terse.[Priority 2]
Provide metadata to add semantic information to pages and sites. For example, indicate the
document's author, the type of content, etc.[Priority 2]
Provide information about the general layout of a site (e.g., a site map or table of contents).
Use navigation mechanisms in a consistent manner. [Priority 2]
Provide navigation bars to highlight and give access to the navigation mechanism. [Priority 3]
Group related links, identify the group (for user agents), and, until user agents do so, provide
a way to bypass the group. [Priority 3]
If search functions are provided, enable different types of searches for different skill levels
and preferences. [Priority 3]
Place distinguishing information at the beginning of headings, paragraphs, lists, etc.
Provide information about document collections (i.e., documents comprising multiple pages.).
Another way to create a collection is by building a zipped archive of the multiple pages.
Provide a means to skip over multi-line ASCII art. [Priority 3]
Guideline 14. Ensure that documents are clear and simple.
Ensure that documents are clear and simple so they may be more easily understood.
Consistent page layout, recognizable graphics, and easy to understand language benefit all users.
They help people with cognitive disabilities or who have difficulty reading.
Ensure that images have text equivalents for people who are blind, have low vision,
or for any user who cannot or has chosen not to view graphics.
Use the clearest and simplest language appropriate for a site's content. [Priority 1]
Supplement text with graphic or auditory presentations where they will facilitate comprehension
of the page. [Priority 3]
Create a style of presentation that is consistent across pages. [Priority 3]
It is impossible in this tutorial to give examples of all of the above coding techiques to
assist in Web page accessability. A comprehensive set of example HTML code, however, is provided
at the W3C Web site:
Techniques for Web Content Accessibility Guidelines.
There are a number of Web sites that provide software for testing pages against accessibility
guidelines. For example, bobby.watchfire.com
permits you to enter the URL of your page and receive a report on its compatibility with W3C and
Section 508 Requirements
Under Federal law, U.S. agencies must make their Web sites accessible to people with vision
and hearing impairments, with limited dexterity, and with other disabilities. Section 508, an
amendment to the Rehabilitation Act of 1973, mandates that people with disabilities be given
comparable access to Web-accessible government information as other users; the Act also pertains
to organizations which receive funds from the federal government.
There are sixteen general rules for accessible Web pages in the Section 508 Standards. In brief, the rules for accessible Web pages are:
- Text Tags: A text equivalent for every non-text element shall be provided.
- Multimedia Presentations: Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.
- Color: Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.
- Readability: Documents shall be organized so they are readable without requiring an associated style sheet.
- Server-Side Image Maps: Redundant text links shall be provided for each active region of a server-side image map.
- Client-Side Image Maps: Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.
- Data Tables 1: Row and column headers shall be identified for data tables.
- Data Tables 2: Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.
- Frames: Frames shall be titled with text that facilitates frame identification and navigation.
- Flicker Rate: Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.
- Text-Only Alternatives: A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.
- Scripts: When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.
- Applets and Plug-Ins: When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet.
- Forms: When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
- Navigation Links: A method shall be provided that permits users to skip repetitive navigation links.
- Time: When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.
Details about these guidelines along with links to other resources for Section 508 compatibility
are at the Federal government site www.section508.gov/.