Planning Your Web App for Accessibility

Planning for accessibility means taking the following impairments into account:

• Visual: Includes full or partial blindness, color-blindness, and reduced vision.
• Auditory: Includes full or partial deafness, difficulty hearing, the inability to hear sounds at certain frequencies, and tinnitus.
• Motor: Includes the inability to use a pointing device such as a mouse, restricted movement, lack of fine motor control, excessive trembling or shaking, and slow reflexes or response times.
• Cognitive: Includes learning disabilities, focusing problems, impaired memory, and extreme distractibility.

Before you get started, it’s a good idea to crank up a screen reading application so that you can test out how your web app works when “heard.” If you use Windows, start up the Narrator utility; if you’re on a Mac, fire up the VoiceOver utility.

• Include alternative text for all images. For the visually impaired, a screen reader reads aloud the value of every <img> tag’s alt attribute, so important or structural images should include a brief description as the alt value:

<img src="twitter.png" alt="Icon for link to Twitter">

You don't need to add an alt value for purely decorative images, but you must include the alt tag (set to an empty string: alt="") or your HTML code won't validate.

• Add an ARIA label to all form fields. ARIA stands for Accessible Rich Internet Applications, and it’s a technology for adding accessibility to web apps. When you add the aria-label attribute to an <input>, <select>, or <textarea> tag, the screen reader reads that attribute's text:

<input type="radio"
    id="pony-express"
    name="delivery"
    value="pony"
    aria-label="Pony express delivery option">

• Add a label for all form fields. Adding the <label> tag — either by using the for attribute to reference the id of the corresponding field, or by surrounding the field with <label> and </label> tags — enables the user to select the field by also clicking the label. This increases the target area for clicking, which helps users with unsteady hands. Be sure to add a label for every <input> tag, as well as each <select> and <textarea> tag:

<label for="user-email">Email address</label>
<input id="user-email" type="email">

• Use headings hierarchically. All page headings should use <h1> through <h6> tags, where that order reflects the hierarchy of the heading structure: <h1> is the top-level heading in a section of the page, <h2> is the second-level heading in that section, and so on. Don't skip heading levels (say, by jumping from <h2> to <h4>).
• Use semantic HTML5 page tags. These include
  ,

<header role="banner">
<nav role="navigation">
<main role="main">
<article role="contentinfo">
<section role="contentinfo">
<aside role="complementary">
<aside role="note">
<footer role="contentinfo">

Wait: two role possibilities for the <aside> tag? Yep: Choose the role value that best fits the content of the sidebar.

• Add ARIA roles to non-semantic elements. If your app uses non-semantic elements, such as a jQuery UI or jQuery Mobile widget, you can alert assistive technologies to what the widget does by adding the role attribute and setting it equal to the widget's function in the app. Some example role values are dialog, menu, menubar, progressbar, scrollbar, slider, tab, tablist, tabpanel, and toolbar. For example, here's how you’d add the various tab-related roles to jQuery UI’s Tabs widget:

<div id="my-tabs">
  <ul role="tablist">
    <li><a href="#my-tab-1" role="tab">This</a></li>
    <li><a href="#my-tab-2" role="tab">That</a></li>
    <li><a href="#my-tab-3" role="tab">The Other</a></li>
  </ul>
  <div id="my-tab-1" role="tabpanel">
    This is the first tab's content.
  </div>
  <div id="my-tab-2" role="tabpanel">
    This is the second tab's content.
  </div>
  <div id="my-tab-3" role="tabpanel">
    Yep, this is the third tab's content.
  </div>
  </div>

Check out Mozilla Developer Network’s Using ARIA page to see a complete list of ARIA roles.

• Ensure your app’s colors have sufficient contrast. If text colors too closely match the background color, the text will be hard to decipher, particularly for the visually impaired.

Once your app is on the web, you can check its accessibility by heading over to the Web Accessibility Evaluation Tool (WAVE). Paste your web app’s address into the text box and press Enter/Return to see a report.