WCAG Accessibility Fundamentals

qa-accessibility-wcag-fundamentals-pour -->

A stakeholder asks whether the app is "WCAG compliant," and the honest answer is only meaningful once you can name which criteria, at which level, on which pages. WCAG is not a vibe — it is a numbered checklist, and each item is written in a form you can turn directly into a test case.

WCAG organizes its 80-odd success criteria under four principles, remembered as POUR:

Each criterion has a stable identifier you will see in bug reports and audit tooling: <principle>.<number>.<number>. Read one out loud — criterion 1.4.3, Contrast (Minimum), Level AA:

"The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for … large-scale text … which has a ratio of at least 3:1."

Decompose it into the parts a test needs: 1.4.3 is the address, the ratio thresholds (4.5:1 for normal text, 3:1 for large text — 24 px, or 18.66 px bold) are the assertion, and the exceptions (logotypes, incidental text) are the escape hatches you must justify, not assume. That decomposition is the whole reading skill; every criterion decomposes the same way.

Conformance is defined at three levels, and the levels stack: A is the floor, AA adds criteria and is the level referenced by Section 508, the EU's EN 301 549, and most enterprise procurement — so AA is the default target for any serious product. AAA is a stretch goal; the spec itself says AAA is not intended for all sites. Two scoping rules trip up first-time auditors: conformance requires every page (not a sample) to satisfy the level, and a complete process must be accessible — you cannot claim AA while the checkout payment step is keyboard-trappable, even if every other page passes.

Version discipline matters in interviews and in contracts. WCAG 2.1 AA is the most widely cited target; WCAG 2.2 (published October 2023) added nine criteria — including 2.4.11 Focus Not Obscured, 2.5.7 Dragging Movements, and 2.5.8 Target Size (Minimum), which demands a 24×24 CSS px hit area — and dropped 4.1.1 Parsing as obsolete. A contract saying "WCAG 2.2 AA" therefore legally includes the drag-free and target-size demands that 2.1 never had. When a ticket says "a11y bug," your first move is to cite the criterion: "fails 2.1.1 Keyboard (Level A)" is actionable and verifiable; "not accessible" is neither.

That citation habit also settles arguments about scope. Product pushes back that the custom dropdown "works fine with a mouse," and the criterion answer is clean: 2.1.1 Keyboard (A) has no mouse exception. Analyzing Results and Bottlenecks measured systems against numbers; accessibility measures interfaces against criteria, and the next chapter opens with the cheapest, highest-yield test you can run — the ten-minute keyboard-only pass that needs no tooling.

qa-accessibility-wcag-fundamentals-keyboard -->

Screen-reader users, people with motor injuries, and power users all drive the interface from the keyboard — and so do your users on the day a trackpad driver breaks. A keyboard-only pass costs ten minutes, needs no tooling, and finds a class of bugs no automated audit will ever report. Put the mouse in a drawer and work through the page with Tab, Shift+Tab, Enter, Space, and Esc.

What you are watching for, mapped to criteria:

Two DOM details cause most order-and-reachability failures. tabindex="0" inserts an element into the natural tab order — legitimate for a custom widget, but every positive value (tabindex="3") overrides the document order and reshuffles focus across the whole page as the browser sorts every positive value before everything else. The rule: never use positive tabindex; reorder the DOM instead. tabindex="-1" removes an element from tabbing while keeping it programmatically focusable — exactly right for the <h1> you jump to from a skip link:

<body>
  <a class="skip-link" href="#main">Skip to main content</a>
  <header>…</header>
  <main id="main" tabindex="-1">
    <h1 tabindex="-1">Orders</h1>

The skip link is criterion 2.4.1 (Bypass Blocks, Level A): it lets keyboard users hop the repeated navigation on every page. Make sure it is visible when focused — a skip link hidden with display: none or opacity: 0 is announced by no one and helps no one; the standard pattern is to position it off-screen and slide it in on :focus.

Modals are the richest source of traps. A correct dialog does four keyboard things: moves focus into it on open, cycles Tab within it (a focus trap — here trapping is the requirement, opposite of 2.1.2), restores focus to the trigger on close, and closes on Esc. Test all four. Then test the page behind it: with aria-hidden="true" missing on the background content, a screen reader happily reads the page under the open dialog, which is criterion 4.1.2 Name, Role, Value territory — the subject of the next chapter, where you hear what assistive technology announces rather than inferring it from the DOM.

The keyboard pass is manual by nature — the tab order is the DOM's order plus CSS order plus script, and no static scanner can execute it. What scanners can do is the complement of this chapter, and that division of labor is exactly what Automated Accessibility Audits quantifies.

qa-accessibility-wcag-fundamentals-screenreaders -->

A DOM that "looks right" can announce as garbage. The only way to know what a screen-reader user hears is to run one — and the two you should learn are NVDA on Windows with Firefox (free, from nvaccess.org) and VoiceOver on macOS with Safari (built in; toggle with Cmd+F5). On mobile, VoiceOver (iOS, triple-click the side button) and TalkBack (Android, hold both volume keys) round out the set.

Learn ten NVDA commands and you can audit anything: Insert+Down reads from the cursor; h jumps between headings, k links, g graphics, f form fields, t tables; Tab moves between focusable controls; Insert+F7 opens the Elements List for a structured view of links and headings. That single-letter vocabulary is why semantic HTML is an accessibility feature: NVDA's h/k/g shortcuts traverse roles, so a <div class="heading"> simply does not exist to the user, and criterion 1.3.1 Info and Relationships (A) is exactly the demand that relationships be expressed in markup.

Three announcement defects account for most screen-reader bugs:

• Images with no usable alt. Criterion 1.1.1 (A) requires alt text for informative images and empty alt="" for decorative ones. Missing alt makes NVDA announce the file path (img_2049_final dot png); alt="icon" announces "icon," which is noise. Write alt text that carries the function or information: a product photo in a catalog gets alt="Nikon Z6 II, black, with 24–70mm lens", a decorative divider gets alt="".
• Inputs with no label. Criterion 3.3.2 Labels or Instructions (A). A placeholder is not a label: it vanishes on input, fails contrast in most browsers, and is often skipped by older assistive tech. The association is what matters — <label for="email"> pointing at the input, or aria-label/aria-labelledby when a visible label is genuinely impossible.
• Custom controls with no state. Criterion 4.1.2 Name, Role, Value (A). A <div class="menu"> announces as nothing; a real disclosure button announces "Collapse navigation, button, expanded." The minimum viable ARIA set for interactive widgets is a role, a name, and a state:

<button aria-expanded="false" aria-controls="filters">Filters</button>
<div id="filters" hidden>…</div>
<!-- announcements that follow a click: "Filters, button, collapsed" → "…, expanded" -->

Dynamic updates need live regions (1.3.1/4.1.3): aria-live="polite" for a result count ("23 items found"), assertive reserved for errors. A page that re-renders results silently is, to a screen reader, a page that did nothing.

Two sensory checks complete the manual sweep. Contrast: open DevTools, pick the text color, and the contrast panel prints the ratio against the background — you are asserting 4.5:1 for normal text and 3:1 for large text (1.4.3, AA), and 3:1 for UI component boundaries like input borders (1.4.11, AA). Watch the non-obvious cases: placeholder text, disabled-looking elements that are still interactive, and text over images, where the measured pixel pair is the only one that counts. Zoom and reflow (1.4.10, AA): press Ctrl/Cmd and + to 200 % and confirm nothing is lost — no horizontal scrolling for content, no clipped controls. Everything you just verified by ear and eye is only the half of the job a machine can do on every commit; that half is the next topic, Automated Accessibility Audits.