Accessibility

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

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 blink.
• 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 cursor movement.
• 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 computer-generated voice.
• 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 audio signals.

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 this tutorial.

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 content.

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.

Coding Practices:

• 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 attribute with <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. [Priority 1]

• 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.

Coding Practices:

• 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.

Coding Practices:

• 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. [Priority 2]

• 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. [Priority 2]

• 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.

Coding Practices:

• 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. [Priority 3]

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.

Coding Practices:

• For data tables, identify row and column headers. Use <td> 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 <thead>, <tbody>, and <tfoot> to group rows and use </col> and <colgroup> to group columns. [Priority 1]

• 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. [Priority 2]

• 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.

Coding Practices:

• 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. [Priority 1]

• Ensure that equivalents for dynamic content are updated when the dynamic content changes. [Priority 1]

• 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. [Priority 2]

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.

Coding Practices:

• Until user agents allow users to control flickering, avoid causing the screen to flicker. [Priority 1]

• 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 be provided.

Coding Practices:

• Make programmatic elements such as scripts directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.]

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.

Coding Practices:

• 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. [Priority 1]

• For scripts, specify logical event handlers rather than device-dependent event handlers. [Priority 2]

• 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. [Priority 3]

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 capabilities.

Coding Practices:

• 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.

Coding Practices:

• 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.

Coding Practices:

• 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.

Coding Practices:

• 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). [Priority 2]

• 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. [Priority 3]

• 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. [Priority 3]

• 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.

Coding Practices:

• 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 other guidelines.

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/.

TOP | NEXT: Site Development