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

POUR

This quick guide is organized by the four major principles of WCAG 2.0, which stipulate that content and interface controls must be:

  • Perceivable
  • Operable
  • Understandable
  • Robust

Guidelines and links to techniques for adhering to the POUR principles are listed beneath each principle heading. Further information about WCAG 2.0 can be found on the Understanding WCAG 2.0 webpage.

1. 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>, and <dl>), emphasized or special text (<strong>, <code>, <abbr>, <blockquote>, for example), etc.
  • 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.

back to top


2. 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.
  • Ensure that keyboard focus is always visible.
  • 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, for example a news carousel, that lasts longer than 5 seconds unless it can be paused, stopped, or hidden by the user.
  • 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 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.

back to top


3. 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, umich.edu). Screen readers attempt to pronounce URLs as words, to bad effect.
  • Avoid using institutional abbreviations and acronyms because these are mostly indecipherable to screen reader users (not to mention the rest of us). 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).

back to top


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

back to top