Web Accessibility: A Practical WCAG 2.2 Checklist for Developers

WCAG 2.2 is the current W3C recommendation for web accessibility, and its Level AA conformance is the de facto legal and contractual target for public and commercial websites in most of the world. It defines 87 success criteria organized under four principles — Perceivable, Operable, Understandable, Robust (POUR) — and WCAG 2.2, published as a W3C Recommendation in October 2023, added nine new criteria focused on mobile interaction, cognitive accessibility, and focus management.

What WCAG 2.2 Added: The Nine New Success Criteria

WCAG 2.2 kept everything from 2.1 and added nine criteria. All nine are Level AA except one. These are the criteria most teams miss when they “already conform to 2.1”:

• 2.4.11 Focus Not Obscured (Minimum) (AA): When an element receives keyboard focus, it must not be entirely hidden behind sticky headers, cookie banners, or chat widgets. A partially visible focused element passes; a fully obscured one fails.
• 2.4.12 Focus Not Obscured (Enhanced) (AAA): The stricter version: the focused element must not be obscured at all.
• 2.4.13 Focus Appearance (AAA): A minimum focus indicator area and contrast for the focus ring itself — the strongest statement of the “never remove outline without a replacement” rule.
• 2.5.7 Dragging Movements (AA): Any functionality operated by dragging (sliders, kanban boards, map panning) must have a single-pointer alternative — buttons, selects, or typed input.
• 2.5.8 Target Size (Minimum) (AA): Interactive targets must be at least 24 × 24 CSS pixels, with exceptions for inline links, equivalent spacing, and user-agent-controlled sizes.
• 3.2.6 Consistent Help (A): If a help mechanism (contact info, chat, FAQ link) appears on multiple pages, it must appear in a consistent relative order.
• 3.3.7 Redundant Entry (A): In multi-step processes, information already entered must be auto-filled or selectable in later steps — no re-typing your address for shipping after entering it for billing.
• 3.3.8 Accessible Authentication (Minimum) (AA): Authentication must not require a cognitive function test (puzzles, memorization, transcription) unless an alternative exists — passkeys, password managers, and copy-paste support are the practical fixes.
• 3.3.9 Accessible Authentication (Enhanced) (AAA): The stricter version, removing object-recognition and content-matching tests as well.

One WCAG 2.1 criterion was removed in 2.2: 4.1.1 Parsing, now obsolete because modern browsers and HTML parsers handle duplicate IDs and malformed markup consistently. If your audit checklist still tests 4.1.1, it is stale.

The Four Principles: POUR

Every success criterion hangs off four principles. When you are unsure about a specific case, reason from these:

• Perceivable: Users must be able to perceive the content — alternatives for non-text content (alt text, captions), sufficient color contrast, content that reflows at zoom, no reliance on a single sense.
• Operable: Users must be able to operate the interface — full keyboard access, no keyboard traps, enough time to complete tasks, no seizure-inducing motion, clear navigation and focus.
• Understandable: Users must be able to understand the content and UI — readable language, predictable behavior, input assistance and error recovery, consistent help.
• Robust: Content must work reliably with assistive technologies — valid markup, correct roles and names, status messages that are programmatically determinable.

Conformance Levels: Why AA Is the Target

WCAG defines three levels, cumulative by design — you cannot conform at AA without also conforming at A:

• Level A: The minimum. Missing alt text, keyboard traps, and unlabeled form inputs fail here. Passing A alone is widely considered insufficient.
• Level AA: The standard target. Includes 4.5:1 contrast, consistent navigation, error identification, focus visibility, and most of the 2.2 additions. Referenced directly or by incorporation in law and regulation worldwide.
• Level AAA: The enhanced level. Includes sign-language interpretation for video, 7:1 contrast for normal text, and no context-sensitive help timeouts. The W3C itself notes AAA is not suitable for all content — treat individual AAA criteria as stretch goals, not a blanket target.

Why AA specifically: the European Accessibility Act (EAA, enforceable since June 2025), Section 508 in the US, the ADA as applied through case law and DOJ rulemaking, Ontario's AODA, and EN 301 549 in the EU all anchor on WCAG 2.x at Level AA. Contractual requirements (enterprise deals, public-sector RFPs) almost always specify the same. When someone asks “what level should we hit?” the answer is AA, plus whichever individual AAA criteria suit your content.

Color and Contrast: The Numbers

Contrast is quantified as a ratio between 1:1 and 21:1. The WCAG 2.2 AA thresholds:

• 4.5:1 for normal text (below roughly 18.66px bold or 24px regular).
• 3:1 for large text — 18.66px+ bold or 24px+ regular.
• 3:1 for UI components and graphical objects: input borders, icons that convey meaning, chart elements, focus indicators.

Two common failures: placeholder text in light gray (it is normal text and needs 4.5:1 like everything else — better yet, use a real label), and state communicated only by color (red vs green status dots). Color may never be the only visual means of conveying information — pair it with text, icons, or patterns. Check candidates with a contrast checker (WebAIM's or the TPGi Colour Contrast Analyser) before they reach QA.

Keyboard Navigation and Focus Management

Keyboard accessibility is the backbone of operability: screen reader users, switch-device users, and power users all drive interfaces through the keyboard. Every interactive control must be reachable and operable with Tab, Shift+Tab, Enter, Space, and arrow keys — no mouse-only widgets, nodiv onClick stand-ins for buttons.

Focus management is the part teams get wrong most often. When a dialog opens, focus moves into it (WCAG 2.4.3). While it is open, Tab cycles inside — no keyboard trap (2.1.2). When it closes, focus returns to the element that opened it. When a single-page navigation happens, focus moves to the new page heading or a polite announcement. And never remove the focus outline without an equally visible replacement — with the new 2.4.11 criterion, also make sure sticky headers and floating chat widgets do not obscure the focused element; a common fix is scroll-padding-topset to your header height.

// Minimal focus trap for dialogs (WCAG 2.4.3, 2.1.2)
// The Tab cycle must stay inside the open dialog.
function trapFocus(dialog: HTMLElement) {
  const focusable = dialog.querySelectorAll<HTMLElement>(
    'a[href], button:not([disabled]), textarea, ' +
    'input:not([type="hidden"]), select, [tabindex]:not([tabindex="-1"])'
  );
  const first = focusable[0];
  const last = focusable[focusable.length - 1];

  dialog.addEventListener("keydown", (e) => {
    if (e.key !== "Tab") return;
    if (e.shiftKey && document.activeElement === first) {
      e.preventDefault();
      last.focus();
    } else if (!e.shiftKey && document.activeElement === last) {
      e.preventDefault();
      first.focus();
    }
  });

  // Move initial focus into the dialog (WCAG 2.4.3)
  first?.focus();
}

// On close, return focus to the element that opened the dialog.
function closeDialog(dialog: HTMLElement, trigger: HTMLElement) {
  dialog.hidden = true;
  trigger.focus();
}

Semantic HTML: The Foundation Everything Else Builds On

The cheapest accessibility wins come from using the right element: button for actions, a for navigation, label for form fields, native input types for keyboards and mobile, table with th for tabular data, and a single h1 with a logical heading hierarchy per page. Native elements ship with keyboard behavior, roles, and states already wired — a<button> is focusable, activates on Enter and Space, and announces as a button with zero ARIA. A styled <div> does none of that.

ARIA: The First Rule

The W3C's first rule of ARIA is: do not use ARIA if you can use a native HTML element with the same behavior. ARIA does not add functionality — it only patches the accessibility tree when native HTML falls short. Misused ARIA is worse than no ARIA: role="button" on a div withouttabindex,aria-expanded that never updates, or a label pointing at a non-existent ID actively confuse screen readers.

When you do need ARIA, the patterns that cover most UI:aria-label /aria-labelledby for accessible names,aria-describedby for descriptions,aria-expanded /aria-selected /aria-checked for state,aria-live for dynamic updates, and the WAI-ARIA Authoring Practices Guide (APG) patterns for menus, dialogs, tabs, and comboboxes — consult the APG rather than inventing interaction semantics.

Forms and Error Handling

Forms are where accessibility either compounds or collapses. The AA requirements, in practice:

• Every input has a programmatically associated <label> — placeholder is not a label.
• Errors are identified in text, not just color, and described via aria-describedby.
• Invalid fields carry aria-invalid="true" and error summaries are focusable.
• Instructions and format requirements appear before the input, not only after failure.
• Suggestive correction (WCAG 3.3.3) when unambiguous — “did you mean .com?”
• No session timeouts without warning and extension where users can lose data.

Dynamic status messages — “item added to cart,” “results updated,” “form submitted” — must be announced programmatically via live regions (WCAG 4.1.3, Status Messages):

<!-- Dynamic status updates need a live region (WCAG 4.1.3).
     Use role="status" (polite) for non-critical updates,
     role="alert" (assertive) for errors. -->

<!-- Persistent polite region, present before updates arrive -->
<p role="status" class="sr-only" id="cart-status"></p>

<!-- Persistent assertive region for errors -->
<div role="alert" id="form-errors"></div>

<script>
  // Announce a cart change politely
  document.getElementById("cart-status").textContent =
    "Item added. Cart now has 3 items.";

  // Announce a validation error assertively
  document.getElementById("form-errors").textContent =
    "Email address is invalid. Check the format and try again.";
</script>

<style>
  /* Visually hidden but still announced by screen readers */
  .sr-only {
    position: absolute;
    width: 1px;
    height: 1px;
    padding: 0;
    margin: -1px;
    overflow: hidden;
    clip: rect(0, 0, 0, 0);
    white-space: nowrap;
    border: 0;
  }
</style>

Images and Alt Text

Alt text (WCAG 1.1.1) remains the criterion most sites fail. The decision tree: if the image conveys information, write alt text that conveys the same information in the same amount of detail; if it is decorative (background flourishes, empty spacers), mark it alt="" so screen readers skip it — never omit thealt attribute entirely, which makes the screen reader read the file name. Complex images (charts, diagrams) need a short alt plus a long description nearby. Images of text need the text in the alt — or better, real text styled over the image.

How to Test: A Practical Methodology

No single tool finds everything. A layered approach catches the vast majority of issues before they ship:

Automated scanning

Run axe DevTools (browser extension or axe-core in CI), Lighthouse's accessibility audit, or Pa11y on every page template. Automated tools reliably catch roughly 30–40% of WCAG issues — missing alt text, low contrast, missing labels, broken ARIA attributes — which makes them excellent guardrails, insufficient audits.

Keyboard-only pass

Unplug the mouse. Tab through every page: is focus always visible? Is the order logical? Can you reach and operate every control? Any keyboard traps? This five-minute pass finds more real issues than an hour of automated scanning.

Screen reader testing

Test with NVDA + Firefox on Windows (free, the most-used combination among real users) and VoiceOver + Safari on macOS or iOS. Walk the critical journeys — sign-up, checkout, search — and listen: are landmarks announced, headings navigable, controls named and described, dynamic updates heard? Even 30 minutes per release surfaces issues no scanner can.

Zoom and reflow

Zoom the browser to 200% (WCAG 1.4.4) and check at 320px width (1.4.10 Reflow): no horizontal scrolling of the page body, no content loss, no controls shrinking below their target size. Emulate this with responsive mode at 320 × 256.

The Legal Landscape

Accessibility is no longer only an ethics argument — it is a compliance one. The European Accessibility Acthas applied since June 28, 2025, covering e-commerce, banking, media, and consumer-facing services, with WCAG 2.1 AA incorporated through EN 301 549. In the United States, the ADA (as applied to the web through DOJ rulemaking and a steady stream of website litigation, particularly in California under Unruh), Section 508 for federal agencies, and state-level laws (New York, California) create overlapping obligations. Canada's AODA and the Accessible Canada Act add their own. None of these laws name a technical standard in their statutes — but regulators, courts, and settlement agreements consistently point at WCAG 2.x Level AA as the benchmark. Treat AA as the floor.

Prioritized Checklist

Work top to bottom — the highest-impact, lowest-cost items first:

Print this, wire the automated rows into CI with axe-core, and schedule the manual rows per release. Accessibility that is tested continuously stays fixed; accessibility that is audited once a year becomes a refactor.