# WCAG 2.2 Form Compliance Checklists

WCAG 2.2 form compliance comes down to a small, concrete set of Success Criteria that govern how a form identifies errors, labels its controls, suggests corrections, prevents costly mistakes, and announces status — each mappable to a specific ARIA attribute, DOM structure, or interaction you can audit. This guide turns those criteria into actionable checklists you can run against any form, with the exact ARIA and DOM wiring each one requires and how to verify it.

The criteria below are the ones that actually bite on data-entry forms: 1.4.1 Use of Color, 3.3.1 Error Identification, 3.3.2 Labels or Instructions, 3.3.3 Error Suggestion, 3.3.4 Error Prevention, 4.1.3 Status Messages, plus the focus-order and focus-visibility criteria in the 2.4.x family. Every checklist maps back to the house pattern — <form novalidate> rendering its own accessible errors — and to the renderer contract documented across UX Patterns & Error State Design and the Constraint Validation API Deep Dive.

# How to Read These Checklists

Each section states the Success Criterion and its conformance level, gives a checklist of - [ ] items you can copy into a review ticket, shows the ARIA/DOM wiring that satisfies it, and names the audit method. The criteria are not independent: a single invalid field touches 3.3.1, 3.3.3, 1.4.1, and 4.1.3 at once, which is why the house renderer sets aria-invalid, links a role="alert" message that names a fix, adds a non-color cue, and updates a live region in one pass.

# Prerequisites

# Success Criterion Reference

# SC 1.4.1 — Use of Color (Level A)

Color must never be the only way error state is conveyed. A red border with no text, icon, or aria-invalid is a 1.4.1 failure for color-blind and screen-reader users alike.

• Every invalid field has a text message in addition to any color change
• An icon or text marker (not just hue) signals the error state
• Error text itself meets 4.5:1 contrast against its background
• The :user-invalid red styling is paired with aria-invalid="true", never standalone
• Required-field indicators use a symbol or word, not color alone

<!-- Color is reinforced by an icon and associated text, not used alone. -->
<input id="email" type="email" aria-invalid="true" aria-describedby="email-error" />
<p id="email-error" role="alert" class="field-error">
  <svg aria-hidden="true" class="error-icon" viewBox="0 0 24 24" width="16" height="16" fill="none" stroke="currentColor" stroke-width="2"><circle cx="12" cy="12" r="10"/><line x1="12" y1="8" x2="12" y2="12"/><line x1="12" y1="16" x2="12.01" y2="16"/></svg>
  Enter your email address.
</p>

Audit: grayscale the form (devtools rendering emulation) and confirm every error is still distinguishable. Automated contrast checks live in axe-core accessibility testing.

# SC 3.3.1 — Error Identification (Level A)

When input is rejected, the field in error must be identified and the error described in text. This is the criterion native tooltips fail, because they are inconsistently exposed to assistive technology — the reason the house pattern suppresses them with novalidate.

• Each invalid field carries aria-invalid="true", cleared to "false" on recovery
• A text message describes what is wrong, in addition to any visual cue
• The message is associated to the input via aria-describedby
• On submit, focus moves to the first invalid field or an error summary
• The error text is present in the DOM, not conveyed only through a tooltip or color

function identifyError(input: HTMLInputElement, message: string): void {
  const errorId = `${input.id}-error`;
  const error = document.getElementById(errorId)!;
  error.textContent = message;
  error.setAttribute('role', 'alert');
  input.setAttribute('aria-invalid', 'true');
  // Preserve any existing hint id when adding the error id.
  input.setAttribute('aria-describedby', `${input.id}-hint ${errorId}`.trim());
}

Audit: with a screen reader, submit an invalid form and confirm each error is announced and the field is reachable. The dedicated WCAG 3.3.1 error identification checklist covers this criterion in depth, and the reading ValidityState flags for granular errors recipe shows how to derive a precise message per failure.

# SC 3.3.2 — Labels or Instructions (Level A)

Every control that takes input needs a label or instruction so users know what to enter and in what format.

• Every input, select, and textarea has a programmatic label (<label for>, aria-label, or aria-labelledby)
• Format expectations (e.g. “DD/MM/YYYY”, “8+ characters”) are stated, not implied by placeholder alone
• Hints are associated via aria-describedby, not left as adjacent text the screen reader skips
• Required state is conveyed in text or with aria-required/required, not by color alone
• Placeholder text is never the only label (it vanishes on input and has poor contrast)

<label for="password">Password</label>
<input id="password" type="password" required minlength="8"
       aria-describedby="password-hint" />
<span id="password-hint" class="hint">At least 8 characters, including a number.</span>

Audit: tab through the form with a screen reader and confirm each control announces a name and its instructions. axe-core flags unlabeled controls automatically.

# SC 3.3.3 — Error Suggestion (Level AA)

When the system knows a likely correction, the error message must suggest it — “Enter a date in DD/MM/YYYY format”, not “Invalid date”.

• Error messages name the expected format or value, not just “invalid”
• Out-of-range numeric errors state the allowed range
• Mismatched-confirmation errors say which field to check
• Suggestions are added to the same associated message node, so 3.3.1 and 3.3.3 share wiring
• Suggestions do not expose security-sensitive data (e.g. whether an email exists, where policy forbids it)

function suggestForEmail(input: HTMLInputElement): string {
  if (input.validity.valueMissing) return 'Enter your email address.';
  if (input.validity.typeMismatch) return 'Enter an email like name@example.com.';
  return '';
}

Audit: trigger each constraint and confirm the message tells the user how to fix it. The WCAG 3.3.3 error suggestion patterns page provides the full pattern catalogue, and the messaging style draws on inline error messaging strategies.

# SC 3.3.4 — Error Prevention (Legal, Financial, Data) (Level AA)

For submissions that carry legal commitments, financial transactions, or modify user data, at least one of reversible, checked, or confirmed must hold.

• The submission is reversible, OR the data is checked for errors and the user can correct them, OR a confirmation step lets the user review and confirm
• A review screen restates the entered values before final commit
• Destructive or irreversible actions require explicit confirmation
• Async/server checks run before commit so the user corrects mistakes pre-submission — see asynchronous server checks
• The confirm step is keyboard accessible and announced

Audit: walk the high-stakes flow end to end and confirm a review/confirm or undo path exists. This is a process audit, not an attribute check.

# SC 4.1.3 — Status Messages (Level AA)

Status messages — “3 errors found”, “Email available”, “Saving…” — must be announced by assistive technology without moving focus. That requires a live region.

• Non-focus status updates live in an aria-live region (polite for routine, assertive/role="alert" for urgent)
• The error-summary count (“Fix 3 problems below”) is announced on submit
• Async success/failure (“Email available”) is announced without stealing focus
• The live region exists in the DOM before the message is injected (empty regions announce updates reliably)
• role="alert" is reserved for genuinely interruptive errors, since it preempts the current announcement

<!-- Pre-rendered, empty, so injected text is announced. -->
<div id="form-status" aria-live="polite" class="visually-hidden"></div>

function announce(message: string): void {
  const region = document.getElementById('form-status')!;
  region.textContent = ''; // reset so identical repeated messages still fire
  requestAnimationFrame(() => (region.textContent = message));
}

Audit: with a screen reader, submit the form and trigger async checks; confirm counts and availability results are spoken without focus jumping. Live-region timing on WebKit is occasionally delayed, so verify in the Playwright form validation testing WebKit project.

# Focus Criteria (2.4.3, 2.4.7, 2.4.11)

Error handling routes focus, so the 2.4.x focus criteria apply directly.

• DOM order matches the visual and logical reading order (2.4.3)
• Every control and the error summary have a visible focus indicator (2.4.7)
• Moving focus to an invalid field does not leave it hidden behind a sticky header or toolbar (2.4.11)
• After a failed submit, focus lands on the first invalid field or the summary, never lost to <body>
• Programmatic focus() targets are focusable (native control or tabindex="-1" on a summary container)

Audit: keyboard-only, submit an invalid form and confirm focus is visible, on the right element, and not obscured. The runtime behavior is documented in Focus Management & Keyboard Navigation and the recipe on managing focus after validation failure.

# Common Gotchas

# Gotcha 1 — Color-only error state

<!-- BEFORE: red border only — fails 1.4.1 -->
<input id="zip" class="invalid" />

<!-- AFTER: color + icon + associated text -->
<input id="zip" aria-invalid="true" aria-describedby="zip-error" class="invalid" />
<p id="zip-error" role="alert">Enter a 5-digit ZIP code.</p>

# Gotcha 2 — Placeholder used as the label

<!-- BEFORE: vanishes on input, low contrast — fails 3.3.2 -->
<input type="email" placeholder="Email" />

<!-- AFTER: real label, placeholder optional -->
<label for="em">Email</label>
<input id="em" type="email" placeholder="name@example.com" />

# Gotcha 3 — Generic message that suggests nothing

// BEFORE: fails 3.3.3
return 'Invalid input.';
// AFTER: names the fix
return 'Enter a date in DD/MM/YYYY format.';

# Gotcha 4 — Status injected into a region added at the same time

// BEFORE: region created and filled together — often not announced
const r = document.createElement('div');
r.setAttribute('aria-live', 'polite');
r.textContent = '3 errors found';
document.body.append(r);

// AFTER: region pre-rendered empty, then filled — reliably announced
announce('3 errors found');

# Browser & Assistive-Tech Compatibility Matrix

# Related Guides

• WCAG 3.3.1 Error Identification Checklist — focused checklist and implementation for identifying errors
• WCAG 3.3.3 Error Suggestion Patterns — patterns for suggesting corrections
• axe-core Accessibility Testing — automate the contrast and association checks in CI
• Playwright Form Validation Testing — assert ARIA state and focus on real submissions
• Focus Management & Keyboard Navigation — satisfy the 2.4.x focus criteria

← Back to Testing & Accessibility