ADA website compliance checklist.

1. Perceivable

Information and user interface components must be presentable to users in ways they can perceive — regardless of whether the user is sighted, blind, low-vision, or deaf.

1.1 Text alternatives

1.1.1 Non-text content (Level A)

• Every meaningful image has an alt attribute that describes the content. (manual)
• Decorative images use alt="" (empty, not missing). (auto)
• Icons that convey meaning (close, search, error) have an accessible name via aria-label or visible text. (manual)
• Charts and graphs have a text equivalent — caption, summary, or linked data table. (manual)
• CAPTCHAs offer a non-visual alternative. (manual)

1.2 Time-based media

1.2.2 Captions / 1.2.4 Captions (Live) / 1.2.5 Audio Description (Level AA)

• Pre-recorded video has accurate, time-synced captions — not auto-generated YouTube captions. (manual)
• Live video (webinars, town halls) has captions or a real-time transcription path. (manual)
• Pre-recorded video where the audio is essential has audio description for visual content. (manual)
• Audio-only content has a transcript on the page. (manual)

1.3 Adaptable

1.3.1 Info & relationships / 1.3.2 Meaningful sequence (Level A)

• Headings use <h1>–<h6> in a logical hierarchy, not styled <div>s. (auto)
• Lists use <ul>, <ol>, or <dl> markup. (auto)
• Tables for tabular data use <th> with scope attributes. (auto)
• Form fields are associated with their labels via <label for> or aria-labelledby. (auto)
• Reading order in the DOM matches visual order on the page. (manual)
• Information conveyed by visual position (e.g., “the form on the right”) also has a text-based reference. (manual)

1.3.5 Identify input purpose (Level AA)

• Common input fields use the correct autocomplete attribute (e.g., autocomplete="email"). (auto)

1.4 Distinguishable

1.4.3 Contrast (Minimum, Level AA)

• Body text contrast is at least 4.5:1 against its background. (auto)
• Large text (≥18pt or ≥14pt bold) contrast is at least 3:1. (auto)
• Disabled inputs and ghost buttons don’t need to meet the threshold, but ensure they aren’t mistaken for active controls. (manual)

1.4.4 Resize text / 1.4.10 Reflow / 1.4.12 Text spacing (Level AA)

• Page works at 200% browser zoom without horizontal scrolling, content loss, or overlapping. (manual)
• Page reflows at 320px viewport width without horizontal scrolling. (manual)
• User can override line height (1.5×), letter spacing (0.12em), word spacing (0.16em), and paragraph spacing (2×) without breaking layout. (manual)

1.4.11 Non-text contrast (Level AA)

• Interactive UI components (button borders, focus indicators, form field borders) have at least 3:1 contrast against the adjacent background. (manual)
• Meaningful graphical elements (icons, chart lines) have at least 3:1 contrast. (manual)

2. Operable

User interface components and navigation must be operable — by keyboard, by touch, by switch device, or by voice control.

2.1 Keyboard accessible

2.1.1 Keyboard / 2.1.2 No keyboard trap (Level A)

• Every interactive element (link, button, input, custom control) is reachable and operable using only the Tab, Shift+Tab, Enter, Space, and arrow keys. (manual)
• Focus never gets trapped — modals, chat widgets, video players all release focus on Escape or a clear close action. (manual)
• Tab order matches the logical and visual order of the page. (manual)

2.4 Navigable

2.4.1 Bypass blocks / 2.4.2 Page titled / 2.4.4 Link purpose (Level A)

• Skip-to-main-content link is the first focusable element on the page. (manual)
• Each page has a unique, descriptive <title>. (auto)
• Link text describes the destination — no “click here,” no “learn more” in isolation. (manual)

2.4.6 Headings and labels / 2.4.7 Focus visible (Level AA)

• Headings describe the section they introduce. Form labels describe the field. (manual)
• Visible focus indicator on every interactive element — not removed via outline: none without a replacement. (manual)

2.4.11 Focus not obscured (Level AA, new in 2.2)

• When an element receives focus, the focus indicator is at least partially visible — not covered by a sticky header, cookie banner, or chat widget. (manual)

2.5 Input modalities

2.5.5 Target size / 2.5.7 Dragging movements / 2.5.8 Target size minimum (Level AA, new/expanded in 2.2)

• Touch targets are at least 24×24 CSS pixels (2.2 minimum). 44×44 is the recommended size for primary interactive elements. (auto)
• Any drag-based interaction has a single-pointer alternative (click, tap). (manual)

3. Understandable

Information and the operation of the user interface must be understandable.

3.1 Readable

3.1.1 Language of page / 3.1.2 Language of parts (Level A / AA)

• The <html> element declares the language: <html lang="en">. (auto)
• Inline text in another language is wrapped with the appropriate lang attribute. (manual)

3.2 Predictable

3.2.3 Consistent navigation / 3.2.4 Consistent identification (Level AA)

• Navigation appears in the same place and same order across pages. (manual)
• Components that do the same thing across the site have the same accessible name. (manual)

3.2.6 Consistent help (Level A, new in 2.2)

• If help mechanisms are available (contact info, chat, help link), they appear in the same relative location across pages. (manual)

3.3 Input assistance

3.3.1 Error identification / 3.3.3 Error suggestion / 3.3.4 Error prevention (Level A / AA)

• Form errors identify the field by name and describe what’s wrong, in text — not by color alone. (manual)
• When possible, provide a suggested correction. (manual)
• For consequential submissions (legal, financial, data deletion), the user can review and confirm before final submission. (manual)

3.3.7 Redundant entry / 3.3.8 Accessible authentication (Level A / AA, new in 2.2)

• Information already entered in a session is not asked again unless changing it is the point. (manual)
• Authentication doesn’t require a cognitive function test (memorizing a captcha, transcribing characters) without a non-cognitive alternative. (manual)

4. Robust

Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

4.1 Compatible

4.1.2 Name, role, value (Level A)

• Every interactive element exposes its accessible name, role, and current state to assistive technology — preferably through native HTML, with ARIA used only when no native element exists. (manual)
• Custom components (modals, accordions, tabs, tree views) follow the WAI-ARIA Authoring Practices patterns or use a tested accessible component library. (manual)

4.1.3 Status messages (Level AA)

• Status changes (form-saved confirmations, errors, async results) are announced to screen readers via role="status", role="alert", or aria-live regions — without stealing focus. (manual)

The tooling layer

Don’t hand-run this checklist on every release. Automate the catchable items and reserve the manual time for the rest:

• axe-core in CI. Run on every PR. Catches around 30% of WCAG issues automatically and fails the build on regressions. URCO uses axe-core integrated into the test runner so any accessibility regression blocks merge.
• WAVE. The WebAIM browser extension. Visual overlay of issues on the rendered page — useful when an issue is hard to find in a CI report.
• Lighthouse Accessibility audit. Built into Chrome DevTools and PageSpeed Insights. Runs a subset of the axe-core checks, useful for a quick second opinion.
• Manual screen-reader passes. NVDA + Firefox on Windows. VoiceOver + Safari on macOS and iOS. TalkBack + Chrome on Android. Schedule once a quarter on the conversion-critical flows; ad hoc after any major UI change.
• Keyboard pass. Tab through the entire page from the first element to the last. Confirm focus visible, focus order logical, no traps, every action reachable.

Where to go from here

• What is an ADA compliant website? — the standard the checklist is measured against.
• ADA compliant website examples — sites that demonstrably pass this checklist.
• Website accessibility statement template — what to publish once you’ve closed the gaps.
• Accessibility audit services — the manual deep audit, when self-assessment isn’t enough.

ADA compliance checklist — FAQ.