WCAG Compliance Checklist for Accessible Web Design

An accessible interface lets people complete a task through different input methods, display settings, and assistive technologies. A passing color score is useful, but it is only one part of that experience.

Use a task-based review to find barriers before release. Start with measurable visual checks, then inspect structure, keyboard behavior, forms, and resizing without treating an automated report as a certificate of compliance.

Set a clear review scope

Define the conformance target and the pages or workflows under review. WCAG 2.2 Level AA is a common target, but applicable legal and contractual requirements can differ. A practical audit needs a stated scope rather than an unsupported promise that a whole product is compliant.

Use the UI Contrast & WCAG Accessibility Checker below to evaluate initial color pairs. Record the foreground, background, text size, and state. A result for a default button does not automatically apply to its hover or error state.

Choose representative tasks: creating an account, correcting a form error, opening a menu, and completing the product's central workflow. Include a complex page, not only the polished homepage.

Keep a shared issue record with reproduction steps, affected users, expected behavior, and a suggested test. Prioritize barriers that prevent task completion, while still scheduling smaller problems that accumulate into a difficult experience.

Check visual information beyond color

Normal text generally requires 4.5:1 contrast at Level AA, while qualifying large text requires 3:1. Read the WCAG contrast guidance for the precise definitions and exceptions. Avoid rounding a failing result upward.

Inspect actual rendered backgrounds, especially gradients, images, transparency, and selected states. For variable imagery, provide a stable local surface rather than checking a convenient region that the label never consistently occupies.

Use redundant signals for errors and status. An overdue invoice can include an explicit label and an icon in addition to a red tint. A required field needs an understandable explanation, not only a colored border.

Review essential non-text boundaries and indicators too. Some user interface components and graphical information need 3:1 contrast against adjacent colors under the relevant criterion. Do not assume the text ratio covers every visible part of a control.

Inspect focus indicators against every surface where the control appears. A ring visible on white may disappear on a selected row. Keep decorative borders distinct from the indicator that identifies the current keyboard position.

Preserve semantic structure and keyboard access

Use native elements where they match the task. A button performs an action; a link navigates. Replacing either with a generic container creates unnecessary keyboard and accessibility work.

The WAI page structure tutorial explains headings and landmarks. Build an outline that describes the page, rather than selecting heading levels for their default font sizes. Styling can change independently of semantic level.

<a href="#main" class="skip-link">Skip to main content</a>
<header>
<nav aria-label="Primary">
  <a href="/tools">Tools</a>
  <a href="/resources">Resources</a>
</nav>
</header>
<main id="main">
<h1>Account settings</h1>
<button type="button">Save preferences</button>
</main>

Walk through the interface with Tab and Shift+Tab. The sequence should follow the task and visible layout. Avoid positive tabindex values, which create a separate ordering system that becomes fragile as the page changes.

Test menus, dialogs, and disclosure controls separately. Focus should not disappear behind an overlay or become trapped in ordinary page content. When a dialog closes, returning focus to the opener usually preserves context. Complex widgets need a deliberate interaction pattern, not a collection of improvised key handlers.

Make forms understandable and recoverable

Every input needs an accessible name, usually through an explicit visible label. Placeholder text is not a reliable label because it disappears during entry and may have insufficient contrast.

Associate instructions and errors with the field they describe. Keep messages concrete: explain what failed and how to fix it. Preserve entered data where safe so a validation failure does not force the user to repeat the entire form.

<label for="email">Work email</label>
<p id="email-help">Use the address for your team account.</p>
<input id="email" name="email" type="email"
autocomplete="email" aria-describedby="email-help email-error"
aria-invalid="true" />
<p id="email-error">Enter a complete email address.</p>

Only set the invalid state when an error actually exists, and remove or update the message when the field becomes valid. The example illustrates an error state, not the initial state of every email field.

For dynamic feedback, choose announcements carefully. A short success message may need a polite status announcement, but announcing every keystroke creates noise. Test the flow with a screen reader rather than assuming an ARIA attribute automatically produces a useful result.

Include loading and server failure states in the review. Prevent accidental duplicate submissions without leaving people unable to understand whether anything happened. A spinner alone is not a complete explanation.

Test resizing and maintain the improvements

Increase text size and browser zoom, then inspect narrow layouts. Content preservation matters more than keeping the original composition. Navigation can wrap, cards can stack, and labels can grow, but controls should remain usable without clipped text.

Test at a viewport equivalent to 320 CSS pixels for relevant reflow requirements, accounting for exceptions such as genuinely two-dimensional content. Avoid fixed heights on text containers and do not hide overflow merely to make screenshots look tidy.

Use the contrast tool again after theme or token changes. Related UI design articles and the dark mode guide can help identify visual states that need independent review.

Combine automated checks with keyboard tests, assistive technology checks, and feedback from disabled users where possible. Automation catches certain patterns efficiently but cannot establish that instructions make sense or a workflow is usable.

Make the audit repeatable. Add component-level checks for labels and states, keep regression examples, and assign ownership for unresolved issues. Accessibility work becomes more dependable when acceptance criteria live beside ordinary product requirements rather than in a separate report nobody revisits.

Key takeaways

• State the review scope and conformance target explicitly.
• Check color pairs, focus indicators, and non-color information.
• Prefer semantic elements and verify the complete keyboard path.
• Associate form labels, instructions, and errors programmatically.
• Test resizing, reflow, loading, and failure states.
• Treat manual testing and ongoing ownership as essential parts of accessibility.