Quick Guide

This page gives guidance to web developers in producing accessible web content and is in the form of a checklist. This checklist is not a substitute for running a site through an online validator or for performing manual functional accessibility verification. However, it is a good starting point for coding accessibility into websites and will save time and effort during the validation and functional evaluation processes.

WCAG 2.0 and this checklist are organized into four major principles, which stipulate that content and interface controls must be:

Make sure web content is perceivable

The following guidelines ensure that information and user interface components are apparent to users.

Provide text alternatives for all non-text content

• Provide alternative text for all images, linked images, form image buttons, and image map areas.
• Assign null or empty alt text (alt="") to non-informative images.
• Describe complex images in the page content or on a separate (longdesc) page.
• Give form buttons a descriptive value.
• Use text labels with form inputs.
• Identify embedded multimedia with accessible text.

Provide alternatives for time-based media

• Provide a transcript for non-live, web-based audio (audio podcasts, MP3 files, etc.).
• Provide a text or audio description for non-live, web-based video-only (i.e., video that has no audio track).
• Provide synchronized captions for non-live, web-based video (e.g., Flash, YouTube, and iTunes U videos).
• Provide a transcript for non-live, web-based video.

Create content that can be presented in different ways without losing information or structure

• Use semantic markup to designate headings (<h1>), lists (<ul>, <ol>, <dl>), emphasized or special text (ie. <strong>, <code>, <abbr>, <blockquote>, <em>).
• Use tables for tabular data. Associate data cells with their headers. Use captions and summaries where appropriate.
• Associate text labels with form input elements. Relate form elements with a fieldset and legend.
• Use the coding order to ensure that the reading and navigation order is logical and intuitive.
• Do not reference sound, shape, size, or visual location in instructions.

Make it easier for users to see and hear content including separating foreground from background

• Do not use color as the only method of conveying content or distinguishing visual elements.
• Do not use color alone to distinguish links from surrounding text unless the contrast ratio between the link and the surrounding text is at least 3:1 and an additional indicator (e.g., it becomes underlined) is provided when the link is hovered over or receives focus.
• Ensure that text and images of text have a contrast ratio of at least 4.5:1.
• Ensure that large text (over 18 point/24 pixels or 14 point/19 pixels bold) has a contrast ratio of at least 3:1.
• Ensure that the page is readable and functional when the text size is doubled.
• Do not use an image to present text if you can use text alone.
• Do not produce audio or movement that automatically plays on a page for more than 3 seconds.

Make sure that interface forms, controls, and navigation are operable

The following guidelines ensure that the assistive tech user can operate the interface.

Make all functionality available from a keyboard

Mac users: Read the article "Enabling keyboard navigation in Mac OS X Web browsers" for instructions on how to activate tabbing for the common Mac web browsers.

• Make all page functionality possible using the keyboard only. Keyboard-only navigation is one of the primary requirements for accessibility.
• Avoid coding shortcut and access keys. Exceptions may be made for sites that receive heavy and repeated use (e.g., CTools). If you use shortcuts, ensure that they do not conflict with common browser and screen reader shortcuts - not an easy task.
• Ensure that keyboard focus is never locked or trapped at one particular page element. The user should be able to navigate to and from all navigable page elements using only the keyboard.

Provide users enough time to read and use content

• If a page or application has a time limit, give the user options to turn off or extend the limit.
• Do not code automatically moving or scrolling content that lasts longer than 3 seconds.
• Do not automatically update content (e.g., automatically refreshing a page) without allowing the user to control the timing of the updates.

Do not design content in a way that is known to cause seizures

• Do not code flashing content.

Provide ways to help users navigate, find content, and determine where they are

• Provide a skip navigation link.
• Give each web page a unique and informative page title, a subset of which should match the <h1> heading.
• The <h1> heading should be unique, descriptive of the page content, and be placed directly before the main content. Do not use the site name for all of the <h1> headings in a site.
• Allow the purpose of each link (or form image button or image map hotspot) to be determined from the link text alone, out of context (e.g., as presented in a list of links with a screen reader).
• Avoid using links with the same link descriptions that go to different locations.

Make sure the content and interface are understandable

Make text content readable and understandable

• Use the HTML lang attribute (<html xml:lang="en" lang="en">) to allow screen readers to read the content with the correct language pronunciation.
• Avoid using URLs for link descriptions, unless they are very simple (e.g., google.com, wlu.edu). Screen readers attempt to pronounce URLs as words, often very poorly.
• Avoid using institutional abbreviations and acronyms because these are mostly indecipherable to screen reader users. When necessary to use an acronym or abbreviation, properly define it and use the <acronym> or <abbr> tags.

Make Web pages appear and operate in predictable ways

• Do not allow a substantial change to the page (e.g., spawning a pop-up window, changing keyboard focus, etc.) that could confuse or disorient the user.

Help users avoid and correct mistakes

• Include requirements about a form element within the element's label.
• Notify users about form validation cues and errors in an efficient, intuitive, and accessible manner. Clearly identify the error and allow the user to easily make the correction and resubmit the form.
• Provide sufficient labels, cues, fieldsets/legends, and instructions for required interactive elements (before the relevant elements in the reading order).

Make sure that web content is robust

Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. This means that users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible).

• Validate your code so that it works reliably with assistive technology. Use the W3C Validator or an equivalent.
• Follow the HTML/XHTML specifications and use forms, form labels, frame titles, etc., appropriately.