Accessible with Keyboard

Many users are physically unable to use a mouse, and might be navigating through the page using keyboard alone. Fortunately testing a website with keyboard is a simple accessibility test that requires no special tools or skills. Just try navigating your website using the keyboard only; don’t touch the mouse. Use the tab key to navigate between features, and other keys if doing so would seem to make sense (e.g., Enter or space to “click” the element that currently has focus, arrow keys to move within a widget such as a menu or slider, escape to close a pop-up window). As you do this, consider these questions:
  • Can you access all features?
  • Can you operate all controls?
  • Is it reasonably easy to tell where you are on the page?

Accessible Images

If web pages include images, the content of those images is, by default, inaccessible to people who are unable to see the images. Whether and how to address this issue depends on the purpose of the image within the context of the web page.

 

Simple Informative Images

If images are designed to communicate information to the user, they must be described. If they are complex images with a lot of important detail (e.g., graph, chart, diagram) see the next section on Complex Informative Images. In contrast, if images are simple (e.g., logos, buttons, photographs) a short description should be added to the alt attribute of the <img> element. The description should describe the content of the image as succinctly as possible. The goal is to provide access to the content of the image, without burdening the user with superfluous details.

Additional information is available on the AccessComputing 30 Tips for Web Accessibility site, Tip #1: Add proper alt text to images.


Complex Informative Images

If images contain a lot of important detail (e.g., graph, chart, diagram) these should include a short title or summary in the alt attribute, but a long description that includes more detail should also be provided. A long description can include any HTML necessary to communicate the content of the image, including data tables.

Historically, the long description has been provided on a separate web page. In HTML5, it is now valid to include a long description on the current page. The longdesc attribute is added to the <img> element, has a URL as its value, pointing to the location of the description. The URL can point to a separate page, or to the id of a container on the current page.  If added to the current page, it is ok to hide the description using CSS display:none.

Screen readers and supporting browsers will inform the user that a long description is available, and the user can choose whether they want to read that description.


Decorative Images

If images are used solely for decorative purposes, they should be added to the page using CSS, not with the HTML <img> element. If for some reason an image needs to be added using HTML, the <img> element must have an empty alt attribute (alt=””). This is a standard technique for communicating to screen readers that the image should be ignored.

Accessible Menus

Website navigation menus often include dropdown or flyout menus, where submenus are hidden by default and appear visibly when mouse users hover over or click a top-level menu item.  These sorts of menus can major present accessibility challenges for many groups of users unless they are coded properly.

The University of Washington's Technology Accessibility Specialist Terrill Thompson has explored this problem in depth and provides recommendations in his blog post Accessible Dropdown Menus Revisited.

Accessible Tables

Data tables should not be used to force content into visible columns. This was a frequently abused technique in the past, but multi-column layouts can now be attained using CSS to handle layout and positioning.

That said, data tables are still useful for presenting data in rows and columns. A few specific HTML tags are required in order to ensure that  data tables that are accessible to screen reader users. Without these tags, users who are unable to see the table can find it very difficult or impossible to understand the relationships between table headers and the cells within their scope.

The specific tags required depends on whether the table is simple or complex.


Simple Table

A simple table has a single header at the top of each column, and optionally a single header in the first column of each row. It has no nested columns or rows. To make a simple table accessible, apply the following techniques:

  • Markup all column headers or row headers as table headers using the <th> element.
  • Define the scope of each <th> using the scope attribute (the value of scope can be either “col” or “row”)


Complex Table

A complex table is any table that is not a simple table, as defined in the preceding section. There might be nested rows or columns, or headers might be located in places other than the first row or column. These sorts of tables can be very challenging for screen reader users to understand. To ensure their accessibility, apply the following techniques:

  • Markup all column headers or row headers as table headers using the <th> element.
  • Add a unique id attribute to each <th> element.
  • For every table data cell (<td>), add a headers attribute that lists the id’s of all headers that apply to that particular cell. If more than one header applies to a cell, separate id’s with a space.


Additional Sources of Information

Meaningful Link Text

Screen reader users navigate websites using a variety of techniques. One of those is to pull up a list of links (a feature of most screen readers) and navigate through that list. Given this, link text should be able to stand alone independently of its context. For example, links like “click here” and “more” are meaningless out of context.

Also, speech recognition users can click links with a voice command like “click” followed by the link text. Therefore it’s helpful to keep link text short and easy to say.

For both of these reasons, long URLs should be avoided as link text (short URLs like ucdenver.edu are ok since they’re easy to say and stand-alone independently of context).

HTML Headings

HTML headings serve two purposes for non-sighted users:
  1. They provide an outline of the page, so users can understand how the page is structured, and how all the sections relate to one another.
  2. They provide a target so users can jump from heading to heading with a single keystroke (e.g., the letter “H” in some screen readers)

With the first purpose in mind, headings should be used in proper order whenever possible. That is,  you shouldn’t have H2 headings with no parent H1 heading, and all headings should be in order with no heading levels skipped.

Additional information is available on the AccessComputing 30 Tips for Web Accessibility site, Tip #2: Use Headings Properly.

Effective Use of Color

There are two accessibility issues related to choice of color:

 

Avoid Using Color to Communicate Information

Some users are unable to perceive color differences, or may not perceive color the same way you do. Therefore it is important to avoid using color alone to communicate information. For example, if link text is blue, it should also be underlined so users who are unable to perceive color differences can distinguish links from surrounding text.


Choose Colors with Ample Contrast

Some users have difficulty perceiving text if there is too little contrast between foreground and background. The W3C Web Content Accessibility Guidelines 2.0 require that color combinations meet clearly defined contrast ratios. In order to meet the guidelines at Level AA, text or images of text must have a contrast ratio of at least 4.5:1 (or 3:1 for large text). In order to meet the guidelines at the stricter Level AAA, the contrast ratio must be at least 7:1 (or 4.5:1 for large text).

Several free tools have been developed that make it easy to check color combinations for WCAG 2.0 compliance. Following are a few examples: