Cannon Access

08 Apr 2009

Accessibility Checklist, Version 1

Last year, I posted an accessibility checklist on North Temple. I don’t generally like to recommend these sorts of lists, because they tend to get abused. People think that the checklist is all they need to make their site accessible. You should only use an accessibility checklist to make sure you didn’t forget anything, or to give you ideas on what to study further.

The size and nature of this checklist makes it impractical for me to provide anything more than the briefest of summaries of each topic, so if you’re relying on it as a tutorial, rather than as just a checklist, your accessibility efforts will almost certainly fall short. I of course also wasn’t able to cover every possible accessibility issue, but only the most common.

So, with the above limitations in mind, here is the Accessibility Checklist, version 1. Watch this blog for version 2, coming soon.

Accessibility Checklist

Markup

  • Separate structure from presentation and use proper markup for that structure. For example, mark up lists as lists (<ul>, <ol>, <dl>) rather than text with a <br> tag after each list item.
  • HTML headings (e.g. <h1>) are very helpful for blind users. Properly mark up the sections of a page and body copy with HTML headings rather than something such as a <p> tag with CSS styling that makes it look like a heading.
  • Give pages meaningful and accurate titles using the <title> tag.
  • Indicate the primary human language of the document using the lang attribute in the <html> tag, and indicate any passages in a secondary language using the lang attribute on other tags wrapping the relevant text (e.g. "<span lang="es">Hola</span> means Hello").
  • Provide “Skip to content” links at the top of the markup order in pages with large numbers of navigational links before the main content.
  • Always indicate headers in data tables using <th> tags, and associate all data cells with their header.
  • Be sure tab order is logical using tabindex, if necessary. (If your HTML is in the proper order, then using tabindex isn’t necessary.)

Visual Appearance and Content

  • Be sure your page is still usable when images are turned off. (This may include making sure that contrast is still sufficient if you happen to be using a background image and that image is removed.)
  • Be sure pages remain usable when users enlarge text up to twice its original size.
  • Be sure each element on a page is reachable and can be manipulated via the keyboard.
  • Whenever possible, write descriptive headings and link texts which can be understood when read out of context (e.g. no “click here” links).
  • For color-blind and low-vision users, be sure your content and background have sufficient contrast.
  • Do not use content that flashes or blinks more than three times a second.
  • Do not hide the focus indicator. When a user uses the keyboard to tab from element to element, it should always be apparent where they are.
  • Do not require users to perceive font, color, or other styling changes in order to understand meaning. For instance, don’t say, “The highlighted word in the previous paragraph is the most important,” or “Items marked in red are errors and need to be corrected,” unless the word or items are indicated in some other way.

Dynamic Content

  • Do not use JavaScript events that radically alter the page or load a new page when fired.

Images and Multimedia

  • Be sure all images have an alt attribute, leaving the text for decorational images blank (e.g. alt="").
  • Always add alt text when images are also links.
  • In general, be brief with alt text (e.g. “the Christus statue”), but provide detail when it conveys meaning (e.g. “President Hinckley’s son standing at his graveside with family in arms”).
  • Provide a transcript, captions, and/or sign language translation for all audio and video with speech.
  • Provide a “described” version of a video when description is necessary for unsighted users to understand content. (The described audio track can either be distributed with the video content, or as an audio only file.)
  • Be sure that all videos, if they don’t autoplay, have, at the very least, an accessible Play control.
  • When text can be rendered just as well by the browser as it can in an image, avoid using images for text. (Image replacement techniques are often an acceptable alternate, but also consider translation requirements when using text in or as images.)
  • Avoid CAPTCHAs unless you have no other choice, and even then they should be avoided. However, if you must use them, provide an audio CAPTCHA alternative.

Forms

  • Always label all form fields with the <label> tag. If a form field has no specific text label on the page, add one, and hide it with CSS or use the title attribute.
  • Use fieldsets (<fieldset>) with legends (<legend>) to associate prompts with radio buttons and check boxes. For instance, a form asks “Gender:” and offers radio buttons that say “Male” or “Female”. Then “Gender:” should be enclosed in a <legend> tag, and all three elements (<legend> and the two radio buttons with their labels) should be enclosed in a <fieldset> tag.
  • Identify all input errors in text (in addition to any images or icons), and place the error notification either next to the affected field or in a prominent location such as the top of the page with an anchor link to the affected field.
  • Provide help links or inline instructions for completing fields when necessary.
  • Do not permit users to complete important actions without a confirmation or a way to undo.
  • Avoid using HTML elements in nonstandard ways (e.g. form elements for navigation, links for form submission, etc.).

Testing

  • Test all pages for markup validation (http://validator.w3.org). If your page does not pass validation, there should be a good reason for it.
  • Test all pages for color blindness using simulators or browser plug-ins. (Recommended: http://colororacle.cartography.ch or http://www.vischeck.com)
  • Test all pages for accessibility (http://wave.webaim.org), but only after you have done all you can to make sure it is accessible using the recommendations in this document.
  • Have your pages reviewed by an accessibility expert.