Web accessibility flashcards

Build pages everyone can see, hear, use and understand: WCAG 2.2, semantic HTML, ARIA done right and real testing.

Beginner friendly, starts from zero

CardsCheatsheetTips and tricks

Web accessibilityStart from zero · 1 of 12

What is web accessibility, in one plain sentence?

Think of the answer, then tap

Building websites and apps that everyone can use, including people who cannot see, hear, move or think in the usual way.

A ramp next to the stairs, but for websites.

Space turn over · K got it · J again · ← back

All topics

Web accessibility at a glance

Web accessibility means building sites and apps that everyone can use, whatever their eyes, ears, hands or mind.

Like a building with ramps, lifts and clear signs: nobody has to ask for help to get in.

Words you will meet

Screen reader: A program that reads the screen aloud for people who cannot see it
Assistive technology: Any tool that helps a person use a computer, like a screen reader or voice control
Focus: The item on the page that the keyboard is ready to use, usually shown with an outline
Alt text: A short written description of a picture for people who cannot see it
Contrast: How different the text colour is from the background, so it is easy to read
WCAG: The world rule book of accessibility checks
ARIA: Extra labels you add to a page when plain HTML cannot say what a part is
Tag: A label in angle brackets that says what a part of the page is, such as a button

The steps

1. Start from zero (12 cards): What accessibility is, who it helps, and the plain words you need before the core basics.
2. Core basics (16 cards): Who accessibility serves, WCAG and POUR, alt text, labels, contrast, keyboard and focus.
3. Next steps (16 cards): Headings, landmarks, skip links, ARIA basics, names and descriptions, form errors, focus order and media.
4. Go deeper (17 cards): The accessibility tree, dialogs, live regions, composite widgets, SPA focus, WCAG 2.2 criteria, testing and law.

All 12 cards in Start from zero

What is web accessibility, in one plain sentence?: Building websites and apps that everyone can use, including people who cannot see, hear, move or think in the usual way.
What goes wrong when a website ignores accessibility?: People get locked out. A blind man cannot book a train ticket, and a man with shaky hands cannot hit tiny buttons, so they give up or ask for help.
Where have you already used accessibility features without noticing?: Captions on a video in a noisy bus, zooming text on your phone, having a page read aloud, or big buttons on a ticket machine. They help everyone, not only disabled people.
Is a disability always lifelong?: No. It can be permanent (one arm), temporary (a broken arm) or situational (holding a baby in one arm). The same design helps all three.
What is a screen reader, and what is assistive technology?: A screen reader is a program that reads the screen aloud, or to braille (raised dots read by finger). Assistive technology is any such helper: screen readers, voice control, magnifiers.
Some people never use a mouse. How do they move around a page, and what is focus?: They press the Tab key to jump from one link or button to the next. The item ready to be used has focus, usually shown with an outline ring around it.
What is alt text, and what are captions?: Alt text is a short written description of a picture, read out to people who cannot see it. Captions are the words of a video's sound, shown on screen for people who cannot hear it.
Why is light grey text on a white page a problem?: It has low contrast: too little difference in brightness between text and background. Contrast is measured as a ratio, and normal text needs at least 4.5 to 1.
How does a screen reader know that a part of the page is a button?: Pages are written in HTML, where each part sits inside a tag that names it, like <button>. The screen reader reads the tag and the words, so it says "Place order, button".
What are WCAG, W3C and ARIA?: WCAG is the world rule book of accessibility checks, written by the W3C, the group that writes web standards. ARIA is extra labels you add when plain HTML cannot say what a part is.
What do you need before you start learning this?: A computer or phone with a browser and a keyboard. Every device already has a free screen reader: VoiceOver on Mac and iPhone, Narrator on Windows, TalkBack on Android. Nothing to install.
What will you be able to do after this topic?: Spot pages that lock people out, test them with only a keyboard and a screen reader, and fix the common problems: missing alt text, weak contrast, lost focus and unlabelled forms.

Web accessibility cheatsheet

Names and descriptions

<label for="id"> Best name for an input
aria-labelledby="id" Name from visible text
aria-label="Close" Name when no visible text
aria-describedby="hint" Extra hint, read after the name
alt="" Decorative image, skipped
aria-hidden="true" Hide decorative icons
class="sr-only" Visually hidden, still read

States and live updates

aria-expanded="true" Disclosure or menu is open
aria-current="page" Current nav link
aria-invalid="true" Field has an error
aria-pressed="true" Toggle button on
role="status" Polite announcement
role="alert" Urgent announcement
inert Remove a region from focus and AT

WCAG 2.2 AA numbers

1.4.3 Text contrast 4.5:1, large 3:1
1.4.11 UI and graphics contrast 3:1
1.4.10 Reflow at 320 CSS px wide
2.4.7 Focus visible
2.4.11 Focus not fully hidden
2.5.8 Targets at least 24x24 px
3.3.8 Login without puzzles, allow paste

Screen reader keys

Cmd + F5 VoiceOver on or off (macOS)
VO + U VoiceOver rotor: headings, links, landmarks
Ctrl + Alt + N Start NVDA
H / D / K NVDA next heading / landmark / link
NVDA + F7 Elements list
Insert + Q Quit NVDA

Testing tools

npm i -D @axe-core/playwright axe in end-to-end tests
npm i -D eslint-plugin-jsx-a11y Lint JSX for a11y bugs
npx lighthouse URL --only-categories=accessibility Quick automated audit
DevTools > Accessibility pane Role, name, state per node
DevTools > Rendering > Emulate vision deficiencies Simulate colour blindness