Web Accessibility Checklist

How to Use This Checklist

Work through it in order, or jump to the categories that match what you are shipping this sprint. For each item, either confirm the page meets it or log a ticket. Where a WCAG success criterion is cited, that is the enforceable reference; the plain-language line is how you explain it to your product team.

• Target WCAG 2.2 Level AA as the baseline. It is the standard adopted by the DOJ ADA Title II rule, referenced by the EU Accessibility Act via EN 301 549, and the direction Section 508 is moving.
• Test both with automated tools and by hand. Automation catches roughly 30-40 percent of issues (Deque, WebAIM research). The rest require keyboard and screen-reader testing.
• Fix issues at the source. Accessibility overlays and widgets do not substitute for accessible code — the FTC’s January 2025 action against accessiBe made that clear.

Text and Typography

• Allow text to resize to 200 percent without loss of content or function. No horizontal scroll, no cut-off buttons, no broken layouts. (WCAG 1.4.4 Resize Text)
• Support reflow at 320 CSS pixels wide. Content must be usable on a narrow viewport without two-dimensional scrolling. (WCAG 1.4.10 Reflow)
• Use real text, not text baked into images. Images of text cannot be resized cleanly, translated, or read by assistive technology.
• Do not rely on color alone to convey meaning. Pair color with icons, underlines, labels, or position. (WCAG 1.4.1 Use of Color)
• Keep line length around 80 characters or less and use comfortable line height (1.5 within paragraphs). (WCAG 1.4.12 Text Spacing)
• Avoid justified text. Uneven spacing between words is hard on readers with dyslexia. Left-align in left-to-right languages.

Color and Contrast

• Body text hits 4.5:1 contrast against its background. Large text (18pt regular or 14pt bold) can drop to 3:1. (WCAG 1.4.3 Contrast Minimum)
• UI components and graphical objects hit 3:1. That includes form-field borders, focus indicators, and icons that carry meaning. (WCAG 1.4.11 Non-text Contrast)
• Test with a real contrast checker, such as the WebAIM Contrast Checker, the TPGi Colour Contrast Analyser, or the Contrast panel in Chrome DevTools.
• Simulate color-vision deficiency. Around 1 in 12 men and 1 in 200 women have some form of CVD (Colour Blind Awareness, NIH). Protanomaly, deuteranomaly, and tritanomaly (the anomalous trichromacies) are more common than the dichromacies — test for both. Use Chrome DevTools Rendering tab, Firefox Accessibility inspector, or the macOS/iOS Color Filters system setting.
• Respect prefers-color-scheme and provide a dark mode if your brand supports it. Low-vision users and people with light sensitivity often rely on it.

Images and Non-Text Content

• Every informative image has an alt attribute that conveys its purpose in context. (WCAG 1.1.1 Non-text Content)
• Decorative images use alt="" so screen readers skip them. Do not use “image of” or repeat the caption.
• Complex images (charts, diagrams, infographics) have a long description available in surrounding text, a linked page, or a <figcaption>.
• Icons that act as buttons or links have accessible names via aria-label, visually hidden text, or paired visible labels.
• SVGs have role="img" and an accessible name when they carry meaning, or aria-hidden="true" when they are decorative.

Video and Audio

• Pre-recorded video has synchronized captions. Auto-generated captions are a starting point, not a finish line — they must be reviewed. (WCAG 1.2.2)
• Pre-recorded audio and video have a transcript. Transcripts help deaf and hard-of-hearing users, low-bandwidth users, and search engines. (WCAG 1.2.1, 1.2.3)
• Live video has real-time captions where feasible. (WCAG 1.2.4)
• Video that is the primary source of information has audio description for visual-only content. (WCAG 1.2.5)
• No media autoplays with sound. If it must autoplay, mute by default and give users obvious controls to pause, stop, or lower volume. (WCAG 1.4.2 Audio Control)
• Nothing flashes more than three times per second above the general or red-flash thresholds — this can trigger seizures in users with photosensitive epilepsy. (WCAG 2.3.1 Three Flashes)

Forms

• Every input has a visible, programmatically associated label. Placeholder text is not a label. (WCAG 1.3.1, 3.3.2 Labels or Instructions)
• Related fields are grouped with <fieldset> and <legend>, or with role="group" and aria-labelledby.
• Required fields are identified in text, not just with color or an asterisk alone.
• Errors are identified in plain language and associated with the field that caused them via aria-describedby or an inline error message. (WCAG 3.3.1 Error Identification)
• Auto-complete attributes are set on common personal-data fields (name, email, tel, postal-code, etc.). (WCAG 1.3.5 Identify Input Purpose)
• Users are not forced to solve a cognitive-function test to authenticate. Offer passkeys, email-magic-link, or OAuth alongside CAPTCHA. (WCAG 3.3.8 Accessible Authentication, new in 2.2)
• Users do not have to re-enter information in the same flow unless essential. (WCAG 3.3.7 Redundant Entry, new in 2.2)

Headings and Page Structure

• Exactly one <h1> per page, describing its topic.
• Headings descend in order — h1, then h2, then h3. Do not skip levels for styling.
• Use real semantic elements: <nav>, <main>, <header>, <footer>, <article>, <aside>. They map to ARIA landmarks automatically. (WCAG 1.3.1)
• A skip-to-main-content link is the first focusable element on the page. (WCAG 2.4.1 Bypass Blocks)
• The page has a descriptive <title> that distinguishes it from other pages on the site. (WCAG 2.4.2 Page Titled)
• The document language is set with <html lang="en">. (WCAG 3.1.1)

Links

• Link text makes sense out of context. Avoid “click here,” “learn more,” or raw URLs. Screen-reader users often tab through a list of links without surrounding copy. (WCAG 2.4.4, 2.4.9)
• Links that open in a new tab warn the user, either in visible text or via an icon with an accessible name.
• Links to files include the file type and size in the link text or an adjacent badge (“Annual Report, PDF, 2.3 MB”).
• Focus moves logically — visited, hover, focus, and active states are all visually distinct.
• Links are distinguishable from surrounding text by more than color (underline, icon, or font weight). (WCAG 1.4.1)

Keyboard and Focus

• Every interactive element is reachable with the Tab key and usable with Enter/Space (and arrow keys where appropriate). (WCAG 2.1.1 Keyboard)
• No keyboard traps. Focus must be able to move away from every component with standard keys. (WCAG 2.1.2)
• A visible focus indicator is present on every focusable element and has 3:1 contrast against the background and unfocused state. (WCAG 2.4.11 Focus Not Obscured (Minimum), new in 2.2; 2.4.7 Focus Visible)
• Tab order matches visual/reading order. Use tabindex="0" where needed and avoid positive tabindex values.
• Custom components (menus, tabs, combos, modals) follow the ARIA Authoring Practices patterns for expected keyboard interaction.
• Modals trap focus while open and return focus to the trigger on close.

Touch and Mobile

• Touch targets are at least 24 x 24 CSS pixels (44 x 44 recommended). (WCAG 2.5.8 Target Size Minimum, new in 2.2)
• Spacing around small targets ensures users do not mis-tap neighboring controls.
• No functionality requires a drag gesture without a single-pointer alternative such as a tap-and-move or arrow-key equivalent. (WCAG 2.5.7 Dragging Movements, new in 2.2)
• Content works in both portrait and landscape. Do not lock orientation unless essential. (WCAG 1.3.4)
• Pinch-to-zoom is not disabled via maximum-scale=1 or user-scalable=no. Low-vision users rely on it.

Motion and Animation

• Honor prefers-reduced-motion by dampening or disabling non-essential animation, parallax, and autoplaying carousels.
• Animations triggered by interaction can be turned off unless the motion is essential to the function. (WCAG 2.3.3 Animation from Interactions)
• Auto-updating content (carousels, live tickers, auto-scrolling lists) can be paused, stopped, or hidden. (WCAG 2.2.2 Pause, Stop, Hide)
• Nothing flashes more than three times per second (see Video and Audio above).

JavaScript, ARIA, and Dynamic Content

• Use native HTML first. A <button> is more accessible than a <div role="button">. The first rule of ARIA is do not use ARIA if HTML gets the job done.
• ARIA roles, states, and properties match the actual component behavior. A role=”tab” must respond to arrow keys. A role=”dialog” must trap focus.
• Dynamic updates are announced via aria-live regions (polite for status, assertive for errors). (WCAG 4.1.3 Status Messages)
• Route changes in single-page apps move focus to the new view’s heading or main content and update the document title.
• Loading states are announced, not just visualized with a spinner.
• Custom widgets expose an accessible name and role through either native semantics or correctly applied ARIA. (WCAG 4.1.2 Name, Role, Value)

Testing and Tools

A real audit combines automated scans, manual keyboard and screen-reader testing, and input from users with disabilities. See the companion guide on manual accessibility testing for a deeper walkthrough.

• Run an automated scan on every page with axe DevTools, WAVE, or Chrome Lighthouse before merging. These catch roughly a third of common issues.
• Tab through the entire page without touching the mouse. Watch for skipped controls, missing focus rings, and illogical order.
• Test with a screen reader. NVDA (free) + Firefox on Windows, VoiceOver (built-in) + Safari on macOS/iOS, or TalkBack on Android. Test at least one combination per release.
• Zoom to 200 percent and narrow the viewport to 320 CSS pixels. Everything should still work.
• Test forms with autofill using browser-remembered profiles.
• Include disabled users in usability testing. Nothing else surfaces the same class of issues — see the guide on how to involve users in accessibility testing.

The 2026 Legal Landscape (Short Version)

• US public sector: the DOJ’s April 2024 ADA Title II rule requires state and local governments to meet WCAG 2.1 AA on phased deadlines through April 2027. See the ADA overview.
• US federal: Section 508 covers federal agencies and the vendors selling ICT to them, using WCAG 2.0 AA as the current reference.
• US private commercial: ADA Title III web-access obligations are enforced case-by-case via DOJ guidance and private litigation. WCAG 2.1 AA is the operative benchmark most courts recognize.
• EU: the European Accessibility Act has applied to new products and services since June 28, 2025, using EN 301 549 (which incorporates WCAG 2.1 AA).
• Global benchmark: WCAG 2.2 AA, published October 2023, is the current W3C recommendation. Targeting 2.2 today means less rework when regulators catch up.

FAQ

What WCAG version should I target in 2026? WCAG 2.2 Level AA. It is the current W3C recommendation and a superset of 2.0 and 2.1. Auditors who still reference 2.1 (because the DOJ ADA rule cites it) will accept 2.2 conformance as meeting 2.1 plus extras.

Do automated tools catch everything on this checklist? No. Deque’s own research puts automated coverage around 30-40 percent of WCAG issues. Contrast, alt text, label associations, and heading order are easy to scan; focus order, keyboard behavior, screen-reader clarity, and error messaging need manual testing.

Is an accessibility overlay enough? No. Overlays do not fix underlying code and have been a recurring source of litigation and regulatory action — the FTC’s January 2025 order against accessiBe being the most visible example. Fix issues at the source.

Does my small business really have to worry about this? If you serve US customers, you are exposed to ADA Title III web-access claims. If you sell in the EU, the European Accessibility Act applies to most B2C digital products and services. And on top of the legal case, accessible sites perform better in search, convert more users, and support an older audience that is growing.

How often should we audit? A full audit annually at minimum, plus a scoped audit on any significant UI or framework change. Automated scans should run in CI on every pull request.

Bottom Line

A usable accessibility checklist is specific, current, and tied to the standards that regulators and auditors cite. Treat this list as a living document — the Perceivable, Operable, Understandable, and Robust categories behind WCAG are stable, but the criteria underneath keep getting sharper. Ship against WCAG 2.2 AA, fix issues at the source, and make manual testing a standing part of your release process.

Dyno Mapper’s accessibility testing tool runs WCAG checks across your whole site on a schedule and tracks regressions over time — useful once the checklist above becomes part of your regular delivery cadence.