From the standard to the user: WCAG and POUR, the accessibility tree with roles, names and ARIA, screen readers and live regions, focus and keyboard models, contrast and motion, and audits.
What WCAG asks, what the browser builds for assistive tech, and how screen readers use it.
The Web Content Accessibility Guidelines: testable success criteria under four principles (POUR) at levels A, AA and AAA; AA is the usual legal target.
in practiceWCAG 2.2 AA in procurement, the EU Accessibility Act and the ADA; audit reports citing criteria like 1.4.3.
Perceivable, Operable, Understandable, Robust: the four principles every WCAG criterion sits under.
in practiceA quick lens in design review: can it be seen or heard, used, understood, and read by assistive tech?
The tree the browser derives from the DOM and ARIA for assistive technology: each node with a role, name, state and value.
in practiceThe Accessibility pane in DevTools; what a screen reader actually reads, which may differ from what you see.
What an element is to assistive tech (button, link, checkbox, dialog, tab), from native HTML semantics or an ARIA role.
in practiceA div with onClick has no role: it is invisible as a control to screen readers.
The text assistive tech announces for an element, computed from aria-labelledby, aria-label, the label element, content or title, in that order.
in practiceIcon buttons with no name ("button" read aloud); getByRole name matching in tests.
Accessible Rich Internet Applications: attributes that add or change roles, names, states and relationships in the accessibility tree; they change nothing else.
in practicearia-expanded on disclosure buttons, aria-live regions; the first rule: use native HTML when it exists.
Regions (banner, navigation, main, complementary, contentinfo, search) that let screen reader users jump around a page.
in practiceheader, nav, main, aside and footer elements; the rotor's landmarks list in VoiceOver.
A logical outline of h1 to h6 that screen reader users navigate by; levels show hierarchy, not font size.
in practiceThe headings rotor; skipped levels and visual-only headings in audits.
Software that reads the accessibility tree aloud or to braille and provides its own navigation (by heading, landmark, link, form field).
in practiceVoiceOver (Apple), NVDA and JAWS (Windows), TalkBack (Android); browse mode versus focus mode.
Screen readers on Windows read pages with their own virtual cursor (browse) and pass keys to the page only in form fields and widgets (focus).
in practiceWhy custom keyboard handlers do not fire for screen reader users until focus mode; role="application" misuse.
An element whose changes are announced without moving focus (aria-live polite or assertive, role status or alert).
in practice"3 results", "Saved", form error summaries, toasts; must exist before content is injected.
Extra text announced after the name and role (aria-describedby), for hints and errors.
in practicePassword rules and inline errors linked to the input.
Focus and keyboard models, the visual requirements, and how products are evaluated.
The single element receiving keyboard input; moved by Tab, by clicks and by script.
in practicedocument.activeElement; focus lost to body after a modal closes or a list item is deleted.
A clearly visible indicator on the focused element; :focus-visible shows it for keyboard users without showing it on mouse clicks.
in practiceoutline: none with no replacement, the most common keyboard failure; WCAG 2.4.7 and 2.4.11.
Focus moves in DOM order; tabindex="0" adds an element to it, "-1" makes it focusable by script only, positive values are an anti-pattern.
in practiceVisual order that differs from DOM order (CSS grid reordering) confusing keyboard users.
Keeping focus inside a modal dialog while it is open, and returning it to the trigger when it closes.
in practiceThe dialog element with showModal(), or inert on the background; focus returning to the button that opened it.
An attribute that makes a subtree unfocusable, unclickable and hidden from assistive tech.
in practiceMaking the page behind a modal or drawer inert; off-screen carousel slides.
In a composite widget (toolbar, tabs, grid), one item has tabindex 0 and the rest -1; arrow keys move it, so Tab enters and leaves the widget in one stop.
in practiceTab lists, menus, radio groups, data grids.
A link at the top of the page, visible on focus, that jumps to the main content past repeated navigation.
in practiceThe first Tab on gov.uk; WCAG 2.4.1 bypass blocks.
The luminance ratio between text and background, from 1:1 to 21:1; AA needs 4.5:1 for body text and 3:1 for large text and UI parts.
in practiceThe contrast picker in DevTools; grey placeholder text failing; brand colours that need a darker text shade.
Meaning must not depend on colour alone: errors need text or icons too, links need more than a hue difference.
in practiceRed-only error borders; charts distinguished only by colour; WCAG 1.4.1.
A media query reflecting the OS setting to reduce motion; parallax, large slides and autoplay should stop or soften.
in practiceVestibular disorders triggered by large movement; replacing slides with fades.
Interactive targets large enough to hit: WCAG 2.2 AA asks for at least 24 by 24 CSS pixels or enough spacing; 44 to 48 is the comfortable norm.
in practiceTiny close buttons and icon rows on mobile.
A structured evaluation of a product against WCAG with automated tools, manual keyboard and screen reader passes, and users with disabilities.
in practiceVPAT and ACR documents for enterprise sales; the quarterly audit plus the CI gate in between.