Simple Accessibility Review Protocol

These are a simple set of heuristics for evaluating the general accessibility of a web application without need for complex assistive technologies or a lot of "under the covers" assessment of the HTML markup and so on.

While this process is by no means a comprehensive method for identifying all accessibility problems, it provides a simple technique that anyone can learn while doing UX Walkthroughs. Instructions for how to conduct a comprehensive accessibility review can be found in a separate section. Additional information about accessibility can be found in the resources page.

Step 1: Assess the overall layout, structure and content of the page

Navigation through poorly structured or overly long pages can often be tedious for users of assistive technologies. A well-organized structure will lead to easier navigation and a clearer sense of the purpose and functionality of various parts of the site for the user. It will also provide a framework for accessibility-specific coding. Scanning the page for overall structure and layout helps to identify problems with labeling and context.

Questions to ask and things to look out for:

  • Is the page structured into logical sections?
  • Are those sections clearly labeled, and is their function apparent?
    • Do paragraphs, sections, and tables have meaningful headings?
    • Is the information in forms grouped in relevant "clumps"?
  • Is site content helpful to users of assistive technology?
    • Can headings, captions and links be understood independently of their surrounding context?
    • Does sentence structure follow writing conventions in a consistent way?
  • Are there sufficient non-visual cues to convey the overall structure? (I.e., Are there sufficient text and/or explanations on the page to understand its purpose and functionality without relying on graphic elements).
  • Are there sufficient visual cues to support page content?
    • Are visual cues recognizable without being differentiated by color?
    • Does there seem to be sufficient contrast between foreground (text) and background colors?
  • Are the most important information and navigational elements prioritized high on the page?
  • Is navigation consistent from page to page? Is the structure of content consistent from page to page?

Step 2: Play around with the layout: enlarge the font size; change the size of the window (bigger and smaller); adjust your resolution

Pages with a fixed or absolute layout will often become unusable if the font size is enlarged or the resolution is lowered. A quick way to assess the layout flexibility of a site is to enlarge the font size by several steps. FireFox is particularly good at this; the Ctrl + shortcut (Cmd + on the Mac) will quickly enlarge the text size in steps. Another technique is to simply lower your screen resolution and see how the page adapts to less screen real estate. Pages should be navigable and content understandable when increased to 4 times the default page.

Questions to ask and things to look out for:

  • Is all the text still visible? Does it overlap?
  • Does visual context break down at large text sizes?
  • Are headers, labels, and visual cues still correctly associated with their content?
  • Do columns shift or realign correctly?

Step 3: Use the Tab key to navigate through the entire page.

Keyboard accessibility is fundamental for the use of many assistive technologies including on-screen keyboards and screen readers. If you can't navigate and use the system entirely with the keyboard, it will be unusable for a lot of people.

The standard convention for traditional Web sites, as defined by the browser, is to cycle through each link on the page using the Tab key, one at a time. Controls such as buttons and links are activated using the Enter key, while selections (such as with radio buttons and checkboxes) are made with the Spacebar, and tables and forms can be navigated using arrow keys. The tab ordering can be customized by the web developer to give users quick access to the most-used areas of the site, even if the visual layout suggests a different order.

With the advent of DHTML and Web 2.0, this convention is changing to more closely mimic the desktop. We'll start to see (and to build ourselves) UIs in which the Tab key simply cycles between major widgets or components on the page (for example, a menu bar). When focus is on the widget, the arrow keys can be used to move up, down, left, and right. Both the Spacebar and Enter keys will activate controls. Give bonus points to user interfaces that use these conventions wisely.

Questions to ask and things to look out for:

  • Do all links and controls receive focus as you tab through the page?
  • Can all controls be activated with the Enter or Space keys?
    • Is movement possible using arrow keys within the object (for example, to move around cells within a table, or within a form)?
  • Does tabbing follow a logical sequence through the page?
  • Is content easily accessible and not secondary to navigational "chrome"? Are navigation and content formats consistent from page to page?
  • Are there any areas where you get stuck and have to use the mouse?
  • Are shortcuts or skip links provided to make keyboard access quicker? Are they visible and clear?

Step 4: Use Internet Explore or Firefox with Popup Alt Attributes Extension to check for alternative text for all images and title text for links.

The most common accessibility oversight is not including text alternatives for visual content. All graphics that provide relevant information should have a short description (around 20 characters maximum) associated with them using the alt attribute. Decorative or meaningless images such as spacer graphics — which probably shouldn't be used in this era of ubiquitous support for CSS - should be given double quotes for alt text (alt="") so they will be ignored by screen readers. If a description cannot be adequately provided with 20 characters, it should be supplemented by text in a longdesc attribute.

Another common oversight is not including title text for links. When link text cannot be made descriptive enough by itself, more of an explanation can be provided through the use of the title attribute.

When you hover over an image or a link with the mouse in Internet Explorer, a tooltip pops up if alt or title text is provided. Use this technique to inspect the graphical content and ensure that meaningful alternative descriptions are provided, and to check if title text has been provided for otherwise non-descriptive links. Note that longdesc content will not be visible in a tooltip.

Firefox and Safari also display a tooltip when you hover over links or images which have a title tag, but do not display anything for (just) an alt tag. According to many, this is the proper implementation of the HTML 4.01 Spec. However, Firefox users may download the Popup Alt Attributes extension to display alt tags when hovering over images as well.