Web accessibility basics: pages everyone can use

A page is accessible when people can use it whatever their body, device or situation: someone who is blind and listens to the page through a screen reader, someone who cannot hold a mouse and moves around with a keyboard, someone reading on a phone in bright sun. Web accessibility basics are not a separate layer you add at the end. Most of them come free with the habits from the earlier chapters, and the rest are a short list of checks you can run in ten minutes. This chapter covers that list, and why each item matters to a real person.

01What accessible means, and who it is for

The W3C's Web Accessibility Initiative puts it simply in its introduction to web accessibility: websites should be designed and built so that people with disabilities can perceive, understand, navigate and interact with them. That covers sight, hearing, movement, speech and how people process information.

It also helps people who would never describe themselves as disabled. Captions help in a noisy train. Good contrast helps on a cheap screen. A form that explains its errors helps someone in a hurry. When you build for the edges, the middle gets a better page too.

The shared rulebook is WCAG, the Web Content Accessibility Guidelines. The current version is WCAG 2.2. It is organised under four principles, often shortened to POUR:

Each guideline is broken into success criteria, which are testable statements graded A, AA or AAA. AA is the level most laws and contracts point to, so it is the one to aim for.

02Structure that assistive technology can read

A screen reader does not see your layout. It reads the HTML: the headings, the landmarks, the links and the buttons, and the names you give them. This is why semantic HTML matters so much. People who use screen readers often jump from heading to heading to scan a page, the way a sighted reader skims. If your headings are styled paragraphs, there is nothing to jump to.

A few rules carry most of the weight:

• Set the language on the root element, <html lang="en">, so a screen reader pronounces the words correctly.
• Use one <h1> and keep heading levels in order. Do not pick a level because of its size; size is the job of CSS.
• Use <header>, <nav>, <main> and <footer> so people can jump straight to a region.
• Use <a> for things that go somewhere and <button> for things that do something. Both get keyboard support and the right role for free.
• Write link text that makes sense out of context. "Read the case study" beats "click here", because screen readers can list every link on a page by itself.

Text alternatives for images

Every <img> needs an alt attribute, but what goes in it depends on why the image is there. The W3C's alt text decision tree walks through the cases. In short: describe what an informative image tells you, describe where a linked image goes, and leave alt empty for pure decoration so screen readers skip it.

<!-- informative: say what it shows -->
<img src="studio.jpg" alt="Two designers sketching a layout on a whiteboard">

<!-- decorative: empty alt, not missing alt -->
<img src="divider.svg" alt="">

03Colour and contrast

Low contrast text is one of the most common accessibility failures, and one of the easiest to fix. WCAG measures contrast as a ratio between the lightness of the text and its background, from 1:1 (identical colours) to 21:1 (black on white).

The contrast minimum criterion asks for at least 4.5:1 for normal text at level AA. Large text, which WCAG defines as 18 point or 14 point bold (about 24px, or about 18.7px bold, in CSS pixels), only needs 3:1, because bigger letters are easier to read. The stricter AAA level raises those to 7:1 and 4.5:1. WCAG 2.2 also asks for 3:1 for the parts of controls and graphics people need to see, such as the border of an input or the lines of a chart.

Pick a text colour and a background colour below and watch the ratio change. Try a light grey on white, the kind you see in a lot of "minimal" designs, and see how quickly it fails.

Two more colour rules sit alongside contrast. First, do not use colour as the only signal. A form field that turns red on error also needs a message, because some people cannot tell red from green. Second, keep links distinguishable from the text around them, usually with an underline.

04Keyboard and focus

Many people never touch a mouse: people with tremors, people who use switch devices, screen reader users and plenty of fast typists. For them the keyboard is the whole interface. The test is simple. Put the mouse aside and press Tab.

• Every link, button and form field should be reachable with Tab, in an order that follows the page.
• Enter should follow a link or press a button. Space should press a button too.
• You should always be able to see where you are.

That last point is the focus indicator, the outline browsers draw around the element that has focus. WCAG's focus visible criterion requires it, yet it is often the first thing removed because someone thought the outline looked untidy. Style it instead of deleting it:

a:focus-visible,
button:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 3px;
}

The :focus-visible selector shows the ring when someone is using the keyboard and usually hides it after a mouse click, which settles the old argument between designers and accessibility.

This is also where progressive enhancement pays off. A menu built from a real <button> works with the keyboard before any JavaScript runs. A menu built from a <div> with a click handler needs extra code for focus, keys and roles, and that code is often missing.

05A ten minute check you can run on any page

You do not need special training to catch most problems. Run these in order:

1. Tab through the page. Can you reach and use everything? Can you always see the focus?
2. Zoom to 200%. Text should grow and wrap, with no content cut off and no sideways scrolling on the main text. The responsive layout from the last part does most of this work.
3. Check contrast of body text, small grey labels and text on images.
4. Look at the headings. A browser extension or the accessibility tree in DevTools lists them. Do they read like a table of contents?
5. Check images. Does each one have sensible alt text, or an empty one if it is decoration?
6. Run an automated tool such as Lighthouse in Chrome DevTools.

When you are working on a real site rather than a practice page, our website accessibility checklist goes further: forms, the criteria WCAG 2.2 added, and how to run a proper audit. Speed is the other half of quality, and it is the subject of the next chapter on website speed.

:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 3px;
}