Accessibility playbook

An accessibility playbook for any product on any stack. Accessibility means that everyone can do everything your product offers. That includes people who are blind, deaf or colour blind, and people who need large text or use a keyboard, a switch or their voice. Many of them are your customers already, and in the EU the European Accessibility Act makes it a legal duty for many services.

The target is WCAG 2.2 level AA. It contains every A and AA criterion, and it covers WCAG 2.1 AA, which most laws name today. Each rule gives the WCAG success criterion it meets, so you can map it to an audit. Every A and AA criterion counts in an audit, whatever its level here. Required marks the ones whose failure blocks a task outright.

The first five chapters cover web pages and web apps. They run from seeing and reading, through keyboard and focus, structure and names, and forms, to touch, motion and sound. The sixth chapter carries the same ideas into native iOS and Android apps. The seventh covers video, PDFs, office documents and email. The last chapter covers the law, the accessibility statement, testing with people and assistive technology, and what to ask for when you buy software.

Check most web rules at once with axe-core on every page type, with the tags wcag2a, wcag2aa, wcag21a, wcag21aa, wcag22aa and best-practice. Run it at phone and desktop width, in light and dark mode, and fail the build on any violation, as in accessibility in CI. Automated tools find only part of the problems. Before each large release, also go through the key tasks with only a keyboard and with a screen reader, as manual accessibility tests says.

Start with Make everything work by keyboard. A page that works by keyboard also works for most switches, voice control and screen readers. Then read Know which accessibility law applies to see what you owe.

Chapters

1. Seeing and reading

   Make text and controls readable for people with low vision or colour blindness, with enough contrast, words beside colour and text that can grow.

   • Required 5
   • Recommended 4
   • Optional 1

2. Keyboard and focus

   Make every control work with a keyboard alone, keep focus visible and in view, and never trap people or steal their keys for shortcuts.

   • Required 3
   • Recommended 3

3. Structure and names

   Build pages from the right HTML elements and name every link and button. Keep navigation in the same place, so screen readers can follow.

   • Required 3
   • Recommended 7

4. Forms, changes and time

   Label every form field, explain errors in words next to the field, announce changes, let people check before they pay and give them enough time.

   • Required 6
   • Recommended 4

5. Touch, motion and sound

   Make tap targets big enough, offer one-tap options for drags and gestures, avoid flashing, respect reduced motion and never play sound by itself.

   • Required 5
   • Recommended 1

6. Native apps

   Carry the same rules into iOS and Android apps, with spoken groups, actions for gestures, large touch targets and the system's motion and display settings.

   • Recommended 6

7. Media, documents and email

   Caption and describe video, put caption buttons beside play, publish tagged PDFs that pass PDF/UA, and check every email template like a web page.

   • Required 2
   • Recommended 5

8. Law, testing and buying

   Know which law applies and publish how each service meets it. Test with assistive technology and disabled people, and ask for a conformance report when buying.

   • Required 1
   • Recommended 6
   • Optional 1
   • Avoid 1

All 64 rules on one page

This is a lot to check. An Expert can check it for you.

Related playbooks

• Non-functional tests

  In the Testing playbook. The automated scan in every build and the keyboard and screen reader runs before each release are written there.

• Product and sector laws

  In the Compliance and governance playbook. The European Accessibility Act is a legal duty for many services. Record whether it covers you and audit every year.

• Crashes and quality

  In the Mobile apps playbook. Native apps need spoken labels and text that grows. Test every screen with VoiceOver and TalkBack.

• Layout and accessibility

  In the Email playbook. Email needs the same care as a page. Use headings, alt text and contrast that survives dark mode.