case study
The Accessibility Checklist
I Vowed I’d Never Write
Update: The below checklist is now available in German.
I have said on numerous occasions that there is no simple checklist that, when followed, will give you an accessible site without fail. There are simply too many variables. But, what do you do when you want to create accessible pages and you have dozens or even hundreds of developers who (like most of their peers) have little to no experience with accessibility? What do you do when it just simply isn’t practical to have someone review all of your pages? In short, how do you insure that a very large organization creates pages that can be accessed by the largest audience possible without drastically increasing your budget? This is one of the questions we have been (and continue to) struggle with.
I believe that in order to solve this problem, we will need to take a multi-faceted approach. However, one element which seems inevitable is training for our designers and developers. I don’t think it’s reasonable (no matter how much I would like to try) to make our devs and designers into accessibility experts, so what can we do? If we can’t yet achieve excellent accessibility, what about simply doing better than we are doing now?
When I wrote the below checklist, I attempted to answer the question, “What concise pieces of advice can I give to designers that will have the greatest impact on accessibility in the majority of cases?”
Again, this list is not the perfect solution, nor is it the only solution, but I believe it is a good first step, and it gives our developers and designers a place to start from.
It is my hope that most of the below points should be easily understood, but on our internal WIKI, we will also be providing links from most checkpoints to supporting documentation that gives more details. For everyone else, I recommend WebAIM or failing that, Google.
A printable version is available here.
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
langattribute in the<html>tag, and indicate any passages in a secondary language using thelangattribute 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 usingtabindexisn’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
altattribute, leaving the text for decorational images blank (e.g.alt=""). - Always add
alttext when images are also links. - In general, be brief with
alttext (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 thetitleattribute. - 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.
5 comments
Simple random Q&A would be a better alternative such as ‘is night dark or bright?’
Also have to make sure Dave Shea’s enhanced image replacement (the bottom one) is used or the text underneath won’t be visible with images turned off.
comment by Yang Yang 89 days later
Excellent list! I’m glad to read something which is not hard to understand, but concise enough to help developers create a very accessible web site.
comment by Tom 104 days later
Thanks for the nice break-down.
comment by Jack McDaniel 110 days later
Great checklist, this points remember me that I have to do some changes in my structures.
comment by Angel 177 days later
This is a great list – especially for those who don’t have any others to review the pages before they need to be published. Instead of waiting a day for someone else to check me, I can just use this list as a reference. Thanks!
comment by Booklet Printing | PrintPlace 194 days later
Comment preview
comment by you less than a minute ago