Universal Webpage Guidelines

The following guidelines are exerpted from the W3C's Web Accessibility Initiative (WAI) with some additional comments and examples (identified by note icon and example page icon respectively). Please refer to the complete Web Authoring Guidelines at www.w3.org/WAI/.

 

A.1 Provide alternative text for all images, applets, and image maps.

This includes images used as submit buttons, bullets in lists, and all of the links within an image map as well as invisible images used to layout a page. Alternative text does not describe the visual appearance of an image, applet, or image map. Rather, it is used to represent the function that the image, applet, or image map performs whether it be decorative, informative, or for purposes of layout. If alternative text is not provided, users who are blind, have low vision, or any user who cannot or has chosen not to view graphics will not know the purpose of the visual components on the page.

Techniques:

  1. For all images (IMG) provide alt-text (via the "alt" attribute). Note. This includes images used as image maps, spacers, bullets in lists, and links.
  2. For all applets (APPLET) provide alt-text (via the "alt" attribute) and content.
  3. For all image map links (AREA)
  4. If OBJECT is used to incorporate an image, applet, or script into a page, use any of the many ways to convey that information in cases where the OBJECT cannot be perceived (e.g., with "title" or within the body of the OBJECT element).

 

Click to view example pagelink to example page

A.2. Provide descriptions for important graphics, scripts, or applets if they are not fully described through alternative text or in the document's content.

Otherwise, important information presented graphically (charts, billboards, diagrams) will not be perceivable to people with blindness, some people with low vision, and users who have chosen not to view graphics, scripts, or applets or whose browser does not support scripts or applets.

Techniques:

  1. Provide a long description of all graphics that convey important information. To do so:
  2. If OBJECT is used to incorporate an image, applet, or script into a page, and it presents important information, use any of the many ways to provide a long description of the information in cases where the OBJECT cannot be perceived (e.g., within the body of the OBJECT element).

 

Click to view example pagelink to example page.

A.3. Provide textual equivalents (captions) for all audio information

If the audio is associated with a visual presentation (movie or animation), synchronize the textual equivalents with the visual presentation. Otherwise, users who are deaf, or hard of hearing, or any user who cannot or has chosen not to hear sound cannot perceive the information presented through speech, sound effects, music, etc.

Techniques:

  1. For stand-alone audio files provide a textual transcript of all words spoken or sung as well as all significant sounds.
  2. For audio associated with video, provide a textual transcript (of dialog and sounds) synchronized with the video (e.g., captions).
  3. Where sounds are played automatically, provide visual notification and transcripts.

A.4. Provide verbal descriptions of moving visual information in both auditory and text form (for movies, animations, etc.).

If the visual presentation is associated with an auditory presentation (e.g., for a movie), synchronize the audio version of the descriptions with the existing auditory presentation and collate the text version of the descriptions with the text transcript (captions) of the primary audio track. Otherwise, if actions, body language, or other visual cues present information that is not expressed through auditory means as well (through dialogue, sound effects, etc.), users who cannot see (or look at) the page will not be able to perceive it. The collated text version allows access to the information by devices that do not play movies and by people who are deaf-blind.

Techniques:

  1. For short animations such as animated "gifs" images, provide alt-text (see A.1)and a long description (see A.2) if needed.
  2. For movies, provide auditory descriptions that are synchronized with the original audio. Click for an example of descriptive video . (clip provided by WGBH )
  3. Provide a text version of the auditory description that is collated with the text transcript (captions) of the primary audio track.

A.5. Ensure that text and graphics are perceivable and understandable when viewed without color.

Otherwise, if color is used to convey information, users 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 blindness.

Techniques:

  1. Don't use color to convey information unless the information is also clear from the markup and/or text.
  2. Use foreground and background color combinations that provide sufficient contrast when viewed by someone with color blindness or when viewed on a black and white screen.

 

Click for an example of a poorly designed page
Click for an example of an accessible page

A.6. Indicate structure with structural elements, and control presentation with presentation elements and style sheets.

When structural elements and attributes are used to create presentation effects, user agents that allow users to navigate through the structure will be unable to do so properly. Such practices also make it difficult to render the page on other media and devices. For instance, don't use H1 to create large, bold face text unless that text is actually a top-level heading.

Techniques:

  1. Nest headings properly (H1 - H6).
  2. Encode list structure and list items properly (UL, OL, DL, LI).
  3. Mark up quotations with the Q and BLOCKQUOTE elements. Do not use them for formatting effects such as indentation.
  4. Use style sheets to control layout and presentation wherever possible as soon as a majority of browsers in use support them well (see A.9). Until then, simple tables (to control layout) and bitmap text with alt-text (for special text effects) may be used, with alternative pages used as necessary to ensure that the information on the page is accessible (see C.1).
  5. Use relative sizing and positioning (e.g., percent) rather than absolute (e.g., pixels or point).

A.7. Ensure that moving, blinking, scrolling, or auto-updating objects or pages may be paused or frozen.

Some people with cognitive limitations 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. People with photosensitive epilepsy can have seizures triggered by flickering or flashing in the 4 to 59 flashes per second (Hertz) range with a peak sensitivity at 20 flashes per second.

Techniques:

  1. Movement should be avoided when possible, but if it must be used, provide a mechanism to allow users to freeze motion or updates in applets and scripts or use style sheets and scripting to create movement. (see also A.10)
  2. For auto-refreshing or timed response pages, provide a second copy of the page where refresh only happens after a link has been selected (until user agents provide this ability themselves).
  3. Avoid any blinking or updating of the screen that causes flicker.

Note 1. BLINK and MARQUEE are not defined in any W3C HTML specification and should not be used. See C.1

Note 2. See also A.4.1 which discusses animated "gifs."

A.8. Provide supplemental information needed to pronounce or interpret abbreviated or foreign text.

Unless changes between multiple languages on the same page are identified, and expansions for abbreviations and acronyms are provided, they may be indecipherable when spoken or brailled.

Techniques:

  1. Use the "lang" attribute to clearly identify changes in the language of text.
  2. For abbreviations and acronyms use either ABBR or ACRONYM with the "title" attribute to specify the expansion.

A.9. Ensure that pages using newer W3C features (technologies) will transform gracefully into an accessible form if the feature is not supported or is turned off.

Some more recent features that are not completely backwards compatible include frames, scripts, style sheets, and applets. Each release of HTML has included new language features. For example, HTML 4.0 added the ability to attach style sheets to a page and to embed scripts and applets into a page. Older browsers ignore new features and some users configure their browser not to make use of new features. These users often see nothing more than a blank page or an unusable page when new features do not transform gracefully. For example, if you specify an image as the source of a frame (via the "src" attribute), then there is no simple way to attach alt-text (see A.1) to that image.

Techniques:

  1. Frames:
    1. Provide a fallback page for pages that contain frames (e.g., by using NOFRAME).
    2. Ensure that the source of each frame is an HTML file.
  2. For scripts that present critical information or functions, provide an alternative, equivalent presentation or mechanism (e.g., by using NOSCRIPT).
  3. For pages that use style sheets, ensure that the contents of each page are ordered and structured so that they read appropriately without the style sheet.
  4. Applets: (embedded using OBJECT or APPLET)
    1. At a minimum:
    2. If possible, provide an alternative function or presentation in a format other than an applet. For example, a canned "mpeg" movie of a physics simulation (written in Java) or a single frame of the animation saved as a "gif" image.


See also C.1.2 - alternative pages.

A.10. Elements that contain their own user interface should have accessibility built in.

The accessibility of objects with their own interface is independent of the accessibility of the user agent. Accessibility must therefore be built into the objects or an alternative must be provided (see A.11.4).

Technique:

  1. Where possible make applets directly accessible (see also A.9.4), if information or functionality is important, and not presented elsewhere.

A.11. Use features that enable activation of page elements via input devices other than a pointing device (e.g., via keyboard, voice, etc.).

Someone who is using the page without sight, with voice input, or with a keyboard (or input device other than a pointing device, e.g., a mouse or braille display) will have a difficult time navigating a page if operation requires a pointing device. If a page is usable via a keyboard, it is more likely that it should also be operable via speech input, or a command line interface. Access to image maps is impossible for these users if alternatives are not provided.

Techniques:

  1. For image maps, provide alternative text for links. (see also A.1)
  2. If possible, ensure that all elements that have their own interface are keyboard operable (see also A.11).
  3. Create a logical tab order through links, form controls, and objects (via the "tabindex" attribute or through logical page design).
  4. Provide keyboard shortcuts (via the "accesskey" attribute) to links (including those in client-side image maps), form controls, and groups of form controls).

A.12. Use interim accessibility solutions so that assistive technologies and older browsers will operate correctly.

Older browsers are unable to "Tab" to edit boxes, text areas and lists of consecutive links, making it difficult to impossible for users to access them. Users not operating in a graphical environment are disoriented by being transferred to a new window without warning.

Techniques:

Until most users are able to secure newer technologies that address these issues:

  1. Include default, place-holding characters in edit boxes and text areas.
  2. Include non-link, printable characters (surrounded by spaces) between links that occur consecutively.
  3. Do not use pop-up windows, new windows, or change active window unless the user is aware that this is happening.
  4. For all form controls with labels, ensure that the label that is either:
  5. Until user agents and screen readers are able to handle text presented side-by-side, all tables that lay out text in parallel, word-wrapped columns require a linear text alternative (on the current page or some other).

B. Context and Orientation

Provide context and orientation information for complex pages or elements.

To provide context and orientation information means that additional information is provided to help users gain an understanding of the "big picture" presented by a page, table, frame, or form. Oftentimes users are limited to viewing only a portion of a page, either because they are accessing the page one word at a time (speech synthesis or braille display), or one section at a time (small display, or a magnified display).

To create documents that provide context and orientation information, authors should:

  1. Structure and group information.
  2. Clearly label the structure and groups.

Guidelines B.1-B.3 address these issues.

B.1. For frames, provide sufficient information to determine the purpose of the frames and how they relate to each other.

Users with blindness and low vision often access the screen with "tunnel vision" and are unable to get an overview understanding of the page. Complex relationships between frames may also be difficult for people with cognitive disabilities to use.

Techniques:

  1. Provide titles for frames (via the "title" attribute on FRAME) so that users can keep track of frames by name.
  2. Use "longdesc" (where needed) to associate a more complete description (than is provided by the title) directly with the frame. Until "longdesc" is widely supported, also use a d-link or invisible d-link.

B.2. Group controls, selections, and labels into semantic units.

This provides contextual information about the relationship between controls, which is useful for all users.

Techniques:

  1. Group form controls (using the FIELDSET and LEGEND elements) for radio buttons and checkboxes.
  2. Associate labels to their controls (using LABEL and its "for" attribute).
  3. Create a hierarchy of long lists of choices (with OPTGROUP).

 

B.3. Ensure that tables (not used for layout) have necessary markup to be properly restructured or presented by accessible browsers and other user agents.

Many user agents restructure tables to present them. Without appropriate markup, the tables will not make sense when restructured. Tables also present special problems to users of screen readers.

These guidelines benefit users that are accessing the table through auditory means (e.g., an Automobile PC which operates by speech input and output) or viewing only a portion of the page at a time (e.g., users with blindness or low vision using speech or a braille display, or other users of devices with small displays, etc.).

Techniques:

  1. Provide summaries for tables (via the "summary" attribute on TABLE).
  2. Identify headers for rows and columns (TD and TH).
  3. Where tables have structural divisions beyond those implicit in the rows and columns, use appropriate markup to identify those divisions (THEAD, TFOOT, TBODY, COLGROUP, the "axis" and "scope" attributes, etc.).
  4. Provide abbreviations for header labels (via the "abbr" attribute on TH).

B.4. Wherever possible, create "good" link phrases.

"Good" link phrases:

"Auditory users," people who are blind, have difficulty seeing, or who are using devices with small or no displays are unable to scan the page quickly with their eyes and often use a list of links to get an overview of a page or to quickly find a link. When links are not descriptive enough, do not make sense when read out of context, or are not unique, the auditory user must stop to read the text surrounding each link to identify it.

Wherever possible:

  1. If more than one link shares the same textual phrase, all those links should point to the same resource.
  2. Avoid phrases that are not meaningful on their own such as "click here."
  3. Avoid creating link phrases that contain full sentences.

C. Good Practices

Maximize usability by following good design practices.

Good design is accessible design and vice-versa. For instance, many of the practices that lead to more accessible pages also make them accessible to indexing engines as well as more usable by all users. Good design practices include consistency, generality, simplicity, reuse, and validation.

C.1. Only use technologies defined in a W3C specification and use them in an accessible manner. Where not possible, provide an accessible alternative page that does.

Many non-HTML technologies (e.g., PDF, Shockwave, and other non-W3C data formats) used to encode information require either plug-ins or stand-alone applications that often create pages that cannot be viewed or navigated using standard Web access tools. Also, W3C technologies may be used in ways that do not transform gracefully (e.g., because the visual components are too complex, or because assistive technologies or user agents (browsers) are lacking a specific feature).  By avoiding non-standard features (elements, attributes, properties, etc. only supported by a specific browser type) and ensuring that all technologies transform gracefully, your pages will be accessible to more people using a wider variety of hardware and software.

Note. Not all PDF pages are accessible or readable after being run through a PDF translator. Individually test each page for readability after the translation process. If a page does not automatically translate, revise the page until its PDF representation converts appropriately through the publicly-available converter(s) or prepare and post an HTML or plain text equivalent.

  1. If W3C technologies are used:
    1. Use the latest W3C specifications whenever possible.
    2. Avoid deprecated elements whenever possible.
  2. If, after all of your best efforts, you can not avoid using a non-W3C technology or any W3C technology in an accessible way then you MUST provide a link to an alternative page that:

     

    Note.  Because of the  difficulty in keeping alternative pages up to date with the full content of the original page, alternative pages should be provided only after you have tried all of the other pertinent techniques outlined in this document to make your original page accessible (unless the alternative page is automatically generated from the same source as the original page).

C.2. Provide mechanisms that facilitate navigation within your site.

Through good design, increase the chance that a person can easily find what they are looking for and can easily navigate throughout the site. Consistent page layouts between pages and a clear navigation structure will not only benefit people with cognitive disabilities, but everyone that visits your site.

To decrease the amount of sifting readers perform to find important information, place distinguishing information at the beginning of headings, paragraphs, lists, etc. This is commonly referred to as "front-loading" and is especially helpful for people accessing information serially.

  1. Create a consistent style of presentation between pages.
  2. Use a clear, consistent navigation structure.
  3. Offer navigation bars for easy access to the navigation structure.
  4. Provide a description of the general layout of the site, the access features used, and how to use them.
  5. Offer a site map.
  6. Offer different types of searches for different skill levels and preferences.
  7. Place distinguishing information at the beginning of headings, paragraphs, lists, etc.

C.3. Create a single downloadable file for documents that exist as a series of separate pages.

This helps people reading documents off-line. Currently, an archival or compression program is needed to create the single file. In the near future, user agents will be able to collate separate pages based on meta information.

  1. Indicate which is the first page of the document and which page follows the current one. (e.g., by using LINK).
  2. Create a bundled version of all pages that comprise the document.

Appendix A: Testing

Validate your pages and assess the accessibility with automated tools, manual tests, and other services.

It is important to test your site with various types of browsers, older versions of current browsers, and services that emulate browsers. Testing your site with a variety of browsers and other services will allow you to gain firsthand experience of some of the issues people deal with. Adjustments to your design based on the results of tests will increase the likelihood that your site will be usable by a wide range of people and technologies.

  1. Use an automated accessibility, and browser validation tool.
  2. Use the W3C HTML Validation Service, available at http://validator.w3.org/
  3. Use the W3C CSS Validation Service, available at http://jigsaw.w3.org/css-validator/
  4. Use a text-only browser or emulator
  5. Use multiple graphic browsers, with:
  6. It may also be helpful to test a site with a self-voicing browser, a screen reader, magnification software, a small display, etc..