WCAG Conformance & Testing

Introduction

WCAG 2.2 conformance defines measurable success criteria at A, AA, and AAA levels — with AA as the legal and procurement standard worldwide. Staff engineers map criteria to HTML patterns, test methods, and release gates rather than treating WCAG as a PDF checklist.

Business problem

Conformance claims without test evidence fail procurement and lawsuits. Teams claim "we follow WCAG" while shipping 2.4.7 focus failures and 1.1.1 missing alts — VPAT becomes inaccurate.

• AA target: Most regulations reference WCAG 2.1/2.2 Level AA — not AAA.
• New in 2.2: Focus Not Obscured, Dragging Movements, Accessible Authentication — affect modals and auth flows.
• Documentation: Accessibility Conformance Report (ACR) requires specific test scope.

Why this feature exists

W3C WAI publishes WCAG as international standard (ISO 40500). Success criteria are technology-agnostic but HTML is primary implementation layer for web — criteria reference element types, ARIA, and keyboard behavior.

• Levels: A = minimum; AA = standard; AAA = enhanced (often not full-site).
• Understanding docs: Each criterion has techniques and failures — engineering spec.
• ACT rules: Standardized automated test rules mapping to criteria.

Browser internals

User agents (browsers) expose accessibility API; AT consumes it. WCAG conformance is about author content + user agent + AT chain — authors control HTML/ARIA/CSS; test across browsers.

• Engines: Blink, Gecko, WebKit differ slightly in name computation — test Safari + Chrome.
• Zoom: 200% reflow (1.4.10) — browser reflow behavior, not author zoom lock.

Rendering workflow

Conformance testing workflow: Define scope (URLs, components) → automated scan → manual test per criterion category → remediate → retest → publish ACR with known exceptions documented.

• Sufficient techniques: H37 (alt on img), H91 (button element) — prefer over ARIA hacks.
• Failures: F65 (alt missing), F44 (meta refresh) — block release.

Feature deep dive

WCAG 2.2 AA criteria commonly tested on HTML products:

• 1.1.1 Non-text Content: alt, aria-label, or decorative alt="" .
• 1.3.1 Info and Relationships: Semantic structure programmatically determinable.
• 2.1.1 Keyboard: All functionality keyboard operable.
• 2.4.7 Focus Visible: Keyboard focus indicator visible (2.2: 2.4.11 Not Obscured).
• 2.4.11 Focus Not Obscured (Minimum): Sticky headers don't hide focused element.
• 3.3.2 Labels or Instructions: Form labels associated.
• 4.1.2 Name, Role, Value: Custom widgets expose correct ARIA/state.

<!-- WCAG 1.1.1 + 1.3.1 + 4.1.2 patterns -->
<img src="chart.png" alt="Q3 revenue up 12% to $4.2M">
<button type="button" aria-pressed="false">Toggle dark mode</button>
<label for="email">Email</label>
<input id="email" name="email" type="email" autocomplete="email" required>

Accessibility analysis

Testing matrix: Automated tools map to ~50 ACT rules; manual required for 2.4.11 (focus obscured), logical focus order, SR announcement order, and cognitive criteria.

• Tools: axe-core, WAVE, Lighthouse accessibility — complementary not duplicate.
• Manual: WebAIM checklist, WCAG-EM evaluation methodology for audits.

SEO impact

WCAG-aligned HTML improves semantic structure Google uses — alt text, headings, lang. Not ranking factor directly but reduces duplicate boilerplate and improves content clarity.

• lang: WCAG 3.1.1 and hreflang both need correct language declaration.

Security considerations

3.3.8 Accessible Authentication (2.2): No cognitive function test without alternative — affects CAPTCHA choices. reCAPTCHA v3 invisible still needs accessible fallback path.

• Session timeout: 2.2.6 Status Messages — warn before expiry accessibly.

Performance impact

2.2.2 Pause, Stop, Hide: Auto-rotating carousels must be pausable — perf-optimized infinite CSS animations need pause control.

• 2.3.3 Animation from Interactions: prefers-reduced-motion CSS — zero perf cost.

Real production example

ACR scope statement excerpt for enterprise SaaS:

• Exceptions: Document with timeline — not silent non-conformance.

Evaluation: WCAG 2.2 Level AA
Scope: app.example.com authenticated app (excludes third-party embeds)
Methods: axe 4.x automated + manual keyboard/SR on 24 critical flows
Browsers: Chrome+NVDA, Safari+VoiceOver, Firefox+JAWS sample
Date: 2026-Q1 | Known exception: legacy PDF viewer (remediation Q3)

Enterprise usage

VPAT 2.5 (ITI) format for procurement — maps WCAG criteria to product support level: Supports, Partially Supports, Does Not Support, N/A.

• Quarterly: Re-evaluate after major UI releases.
• Training: Engineers certified in WAS or CPACC — common hiring target.

Common production failures

False VPAT: Claimed Supports on 2.4.7 but global CSS outline:none — lawsuit discovery. WCAG 2.2 focus obscured by cookie banner — new criterion caught in EAA audit.

• CAPTCHA: No accessible alternative — failed 3.3.8 on login.

Architecture review questions

• Which WCAG 2.2 criteria apply to this feature's HTML?
• Automated vs manual test coverage documented per criterion?
• Focus visible and not obscured by sticky UI?
• ACR exceptions listed with remediation dates?
• Tested on VoiceOver + NVDA minimum?

Hands-on project

Project: Complete WCAG-EM evaluation on checkout flow — spreadsheet mapping 15 AA criteria to pass/fail with evidence screenshots.

• Deliverable: Remediation tickets prioritized by severity and legal exposure.

Interview questions

Try it yourself

Edit the HTML, CSS, or JS panels — the preview updates as you type.

Summary

WCAG 2.2 conformance testing maps W3C success criteria to HTML implementations — staff teams automate ACT-aligned checks in CI, manually validate keyboard and screen reader behavior, and publish accurate ACRs for legal and procurement requirements.