Accessibility: pages that work for everyone

Intermediate

Introduction

Some people navigate by keyboard alone because of a motor impairment. Some listen to pages through a screen reader. Others have low vision and zoom in to 400%, or cannot distinguish red from green. And anyone can be in bright sunlight with a broken arm and a poor connection. Accessibility means building so that all of them can use what you make, and you have already learned most of it.

How it works

Native elements do most of the work. A button can receive focus, responds to Enter and Space, and is announced as a button. Every previous lesson that said "use the real element" was an accessibility lesson. Here is what to check on any page:

  1. Every image has appropriate alt text.
  2. Every input has a label.
  3. Headings form an outline, without skipped levels.
  4. Landmarks divide the page: header, nav, main, footer.
  5. Link text makes sense when read alone.
  6. The html element has a correct lang.
  7. Colour is never the only signal. "Fields in red are required" fails for a colour-blind reader.
  8. Text has enough contrast against its background.

The keyboard. Press Tab to move forward through links and controls, and Shift+Tab to move back. Elements receive focus in the order they appear in the HTML, which is one more reason for your source order to make sense. Browsers show a focus outline. Removing that outline with CSS leaves keyboard users unable to see where they are.

Skip links. A keyboard user should not have to tab through a 30-item menu on every page. A skip link is the first thing on the page, and it jumps to main. Often it is hidden until focused.

ARIA. ARIA attributes give extra information to assistive technology when HTML has no suitable element. The most useful are simple. aria-label names something that has no visible text, such as an icon button. aria-hidden="true" hides a decorative icon from screen readers. aria-live announces content that changes.

The first rule of ARIA, written in the standard's own guidance, is not to use it if a native element will do. ARIA changes only what is announced. role="button" on a div does not make it focusable or clickable by keyboard. It just makes a promise that the element cannot keep.

Syntax

<a class="skip" href="#content">Skip to main content</a>
<main id="content">...</main>
<button aria-label="Close dialog">×</button>

Example

Click in the preview, then press Tab several times and watch the focus move.

console.log output from the page shows here.

Line by line

  1. The skip link is the first thing that receives focus, and it leads to #content.
  2. id="content" is the target, and tabindex="-1" lets it receive focus from the link, without adding it to the Tab order.
  3. The button contains only an icon, so aria-label gives it a name for screen readers.

Expected result

Each press of Tab moves a visible outline to the next link, and then to the button. Activating the skip link jumps past the menu.

In the real world

WCAG, published by the W3C, is the standard that most accessibility laws around the world refer to, often at its AA level. Courts in several countries have ruled against companies with inaccessible websites. The same work also tends to improve search rankings and usability for everyone: captions, for example, are widely used by people watching without sound.

Common mistakes

  • Removing the focus outline with outline: none and adding nothing in its place.
  • Using role="button" on a div in place of a button.
  • Positive tabindex values, which scramble the keyboard order.
  • Using aria-label on elements that have no role, like a plain div, where it is ignored by much software.

Best practices

  • Use native elements before anything else.
  • Test with the keyboard alone, every time.
  • Try a real screen reader: VoiceOver is built into Apple devices, and NVDA is free for Windows.
  • Run an automated checker such as axe, but remember that it can only find some problems.

Summary

Accessibility starts with correct HTML: labels, alt text, headings and landmarks. Everything must work with a keyboard, focus must stay visible, and skip links save effort. ARIA fills gaps and cannot replace native elements.

Quick check

1. What does role="button" on a div do?
2. What is the first rule of using ARIA?
3. Why is 'required fields are in red' a problem?

Key takeaways

  • Most accessibility comes from using the right HTML element.
  • Everything must work with a keyboard alone.
  • No ARIA is better than wrong ARIA.
  • Test by putting the mouse away and pressing Tab.

Practice problems for this lesson

My notes

Write down what you want to remember from this lesson. Notes are saved on this device as you type, and appear on your dashboard.