Web accessibility examples: broken and fixed code

Ten web accessibility examples at a glance

Here are ten digital accessibility examples in one table. The sections after it show code for the trickier ones.

Images and links

Images and links make up a large share of audit findings, and both are quick to fix. Alt text should carry the meaning of the image in this spot on the page, and link text should still make sense when a screen reader lists links on their own.

<img src="IMG_4021.jpg">
<a href="/menu/">Click for more</a>

<img src="stall.jpg" alt="Tea stall counter with
  glass jars of biscuits">
<a href="/menu/">See the full tea menu</a>

For many more image cases see alt text examples.

Form fields and a radio button group

Forms are where users give up. Every input needs a programmatic label, related controls need a group name, and errors need words, not just a red outline. This is the classic WCAG radio button example:

<p>Send me updates?</p>
<input type="radio" name="up" id="y"> Yes
<input type="radio" name="up" id="n"> No

<fieldset>
  <legend>Send me updates?</legend>
  <label><input type="radio" name="up"> Yes</label>
  <label><input type="radio" name="up"> No</label>
</fieldset>

For errors, write the message beside the input and link the two through aria-describedby, as covered in error identification.

A data table with real headers

A data table needs header cells that are marked up as headers, so a screen reader can say "Plan, Basic" as the user moves through the cells. Use tables only for data, never for page layout.

<table>
  <caption>Delivery times</caption>
  <tr><th scope="col">Zone</th><th scope="col">Days</th></tr>
  <tr><th scope="row">City</th><td>1</td></tr>
  <tr><th scope="row">Rural</th><td>3</td></tr>
</table>

Dropdowns and comboboxes

The best WCAG dropdown example is the plain select element. It works with the keyboard, touch and every screen reader with no extra code. Custom dropdowns built from div elements are one of the most common causes of 2.1.1 and 4.1.2 failures.

<label for="size">Cup size</label>
<select id="size">
  <option>Small</option>
  <option>Large</option>
</select>

When users must type to filter a long list, you need a combobox. A WCAG combobox example needs a text input with role="combobox", aria-expanded, aria-controls pointing at a listbox, arrow key support and an announced active option. That is a lot of behaviour to get right, so start from the combobox pattern in the ARIA Authoring Practices Guide and test it thoroughly.

<input id="city" role="combobox" aria-expanded="false"
  aria-controls="city-list" aria-autocomplete="list">
<ul id="city-list" role="listbox" hidden></ul>

Tooltips and dialogs

A good WCAG tooltip example appears on keyboard focus as well as hover, is linked to its trigger so it is read aloud, stays visible while the pointer moves onto it, and closes with Escape. That last set of rules is 1.4.13.

<button aria-describedby="tip1">Share</button>
<span role="tooltip" id="tip1">Copies a link to this page</span>

A good WCAG dialog example pulls focus inside on opening, keeps Tab cycling within, closes on Escape, and hands focus back to whatever launched it. The native dialog element opened with showModal() takes care of most of that.

<dialog aria-labelledby="dlg-title">
  <h2 id="dlg-title">Remove item?</h2>
  <button>Remove</button>
  <button>Cancel</button>
</dialog>

Tabs and date pickers

A WCAG tab example uses three roles. The tab list holds the tabs, each tab says whether it is selected, and each panel is labelled by its tab. Arrow keys move between tabs and Tab moves into the panel.

<div role="tablist" aria-label="Plans">
  <button role="tab" aria-selected="true"
    aria-controls="p1" id="t1">Monthly</button>
</div>
<div role="tabpanel" id="p1" aria-labelledby="t1">...</div>

For a WCAG calendar example, the safest choice is to let people type the date into a labelled field with the format shown, and offer the calendar grid as an extra. Many users of screen readers and voice control find grid pickers slow. The native input type="date" is a reasonable option where browser support suits your audience.

<label for="dob">Date of birth</label>
<span id="fmt">Format: DD/MM/YYYY</span>
<input id="dob" aria-describedby="fmt"
  autocomplete="bday" inputmode="numeric">

What accessible websites have in common

When people ask for web accessibility websites examples, what they really want is the set of habits that well-built sites share. Public sector sites that must publish an accessibility statement are a good place to look. They tend to have:

• A skip link as the first focusable item, visible when focused.
• Landmarks: header, nav, main and footer.
• One h1 and a sensible heading outline.
• A strong, visible focus style on every control.
• Body copy that clears the 4.5:1 ratio, and layouts that reflow on a phone.
• Forms with visible labels and error summaries.
• A published statement about accessibility, plus a way to report barriers.

<a class="skip" href="#main">Skip to main content</a>
<main id="main">...</main>

For the design side see accessible web design.

How to use these patterns safely

Patterns are a starting point, not proof. Copying code is safe only when you also check it in context.

1. Check whether a native HTML element already does the job. If it does, use it.
2. If not, follow the matching pattern in the ARIA Authoring Practices Guide.
3. Test with the keyboard: Tab, Shift+Tab, Enter, Space, arrow keys and Escape.
4. Run a screen reader over it and check what it announces: name, role, state.
5. Zoom to 400 percent and check nothing is lost.
6. Record the result per criterion, then retest after every change.

A structured plan is in accessibility testing, and outside help is described in accessibility audit and accessibility services.