WCAG 2.2 Engineering Practice

Why this chapter matters

Accessibility is a system property, not a QA afterthought. Teams that treat WCAG 2.2 as an architecture baseline ship faster because accessibility requirements are embedded in primitives, workflows, and acceptance criteria.

Core mental model

Adopt three layers of responsibility:

1. Design-system layer: component contracts enforce keyboard/focus/semantics defaults.
2. Feature layer: workflows preserve those guarantees in product-specific flows.
3. Verification layer: automated + manual checks prevent regressions.

Decision framework

Decision	Option A	Option B	Tradeoff signal
Accessibility ownership	Central a11y team	Embedded ownership in every squad	Prefer embedded with central enablement
Testing strategy	Manual-only audits	CI checks + manual exploratory	Prefer hybrid strategy
Component strategy	Ad-hoc widgets	standardized accessible primitives	Prefer primitives for scale

Engineering patterns

Pattern A — Accessibility-by-default components

Every primitive should define:

• semantic role and ARIA contract
• keyboard support model
• focus-visible behavior
• error/help text association model

Pattern B — Focus and navigation architecture

• Use deterministic focus transitions on route/modal/dialog changes.
• Prevent focus loss during async updates.
• Provide skip links and landmark regions on every shell layout.

Pattern C — Form and validation reliability

• Programmatic labels for all controls.
• Clear error associations and summary for multi-error forms.
• Avoid color-only communication and ensure sufficient contrast.

Anti-patterns and failure modes

• Anti-pattern: accessibility fixes after feature completion.

  • Failure mode: recurring regressions and costly rework.
  • Fix: include a11y acceptance criteria in story definition.

• Anti-pattern: ARIA-heavy div-based controls for standard elements.

  • Failure mode: broken keyboard/screen reader behavior.
  • Fix: prefer native elements, then progressive enhancement.

• Anti-pattern: treating automated tools as full compliance.

  • Failure mode: significant usability issues remain undiscovered.
  • Fix: add keyboard-only and screen-reader smoke tests.

Verification checklist

• Keyboard-only navigation works for primary user journeys.
• Focus order is logical and visible under all themes.
• Forms expose labels, errors, and help text semantically.
• Contrast and non-text contrast meet WCAG 2.2 targets.
• CI includes lint/audit checks and release blockers for critical issues.

Metrics and scorecards

Track by release:

• % components with documented a11y contracts
• Critical accessibility defects found pre-release vs post-release
• Keyboard journey pass rate for top user flows
• Time-to-fix for accessibility regressions
• Screen-reader smoke test pass rate

At-scale adaptation

• Define accessibility champions per team.
• Maintain shared a11y test harness for reusable flows.
• Add “accessibility impact” section to architecture RFCs.
• Build a quarterly accessibility debt burn-down plan.

Exercise

Select one complex form flow and produce:

1. Accessibility contract for each component used.
2. Keyboard/focus state diagram.
3. CI and manual verification plan with pass/fail criteria.