Web Accessibility Audit Checklist: 25 Essential Steps

Install the axe DevTools browser extension and scan each unique page layout. Axe catches about 30-40% of WCAG violations automatically — missing alt text, form label issues, color contrast failures. Fix all critical and serious issues before moving to manual testing.

Install `eslint-plugin-jsx-a11y` (for React projects) or equivalent framework plugin. It catches missing alt attributes, invalid ARIA props, and non-interactive elements with click handlers at build time, preventing accessibility regressions before code is even committed.

Add a Lighthouse CI step that fails the build if the accessibility score drops below 90. Lighthouse checks a subset of WCAG criteria automatically and provides a trend over time. Use it as a regression safety net, not as your only testing tool.

Run your pages through the W3C HTML validator (validator.w3.org). Malformed HTML — unclosed tags, duplicate IDs, improper nesting — breaks screen reader interpretation in unpredictable ways. Fix structural errors before testing with assistive technology.

List every unique page template and interactive component in your site. Include pages with forms, modals, tables, tabs, and dynamic content. This inventory becomes your testing scope — you'll test each template once rather than every URL.

Starting from the browser address bar, press Tab repeatedly and verify that focus moves through interactive elements in a logical reading order. Focus should never jump to an unexpected section, get trapped in a component, or skip important controls.

Every link, button, input, and custom control must show a clear visual change when focused. The default browser outline is sufficient, but if you've removed it with `outline: none`, you must replace it with a custom focus style that has at least 3:1 contrast ratio.

Every modal, dropdown, popover, and overlay must close when the user presses Escape. Focus must return to the element that triggered the overlay. Without this, keyboard users get trapped in overlays with no way to return to the main content.

Add a 'Skip to main content' link as the first focusable element on every page. It should be visually hidden until focused, then visible. Without it, keyboard users must Tab through your entire header and navigation on every page load before reaching content.

A keyboard trap occurs when focus enters a component but Tab and Escape can't move it out. Common traps: third-party embeds (maps, video players), custom rich text editors, and carousels. Test by tabbing into every interactive widget and confirming you can tab out.

Navigate your site using a screen reader, not just axe. Listen to how page landmarks, headings, links, and form fields are announced. Screen readers interpret your ARIA roles, labels, and HTML semantics — automated tools only check that they exist, not that they make sense.

Review every image's alt attribute with a screen reader active. Informative images need descriptive alt text (what the image shows, not 'image of...'). Decorative images need `alt=''`. Complex images like charts need a longer description via `aria-describedby`.

Every `input`, `select`, and `textarea` must have a visible `<label>` with a matching `for` attribute, or be wrapped in a `<label>` element. Screen readers announce the label when the field receives focus — without it, users don't know what to enter.

When content updates without a page reload (toast notifications, form errors, live data), verify the screen reader announces the change. Use `aria-live='polite'` for non-urgent updates and `aria-live='assertive'` for errors. Test that announcements are clear and not repetitive.

Use a screen reader's heading navigation (NVDA: H key, VoiceOver: VO+Command+H) to jump through headings. The hierarchy should be logical: one H1 per page, H2 for sections, H3 for subsections. Never skip levels (H2 to H4) — screen reader users rely on heading levels for page structure.

Normal text needs at least 4.5:1 contrast ratio against its background. Large text (18px+ bold or 24px+ regular) needs 3:1. Use a tool like WebAIM's contrast checker or the axe DevTools color picker. Don't forget to check text on images, gradients, and hover states.

Check that error states use icons or text in addition to red color. Verify that chart data uses patterns or labels, not just colors. Form validation should show error messages, not just red borders. About 8% of men have some form of color blindness.

Zoom to 200% and verify that all content remains readable, no text is truncated, horizontal scrolling is not required, and interactive elements are still usable. WCAG requires content to be functional at 200% zoom. Test both desktop and mobile layouts at this zoom level.

All clickable and tappable elements must be at least 44x44 CSS pixels, per WCAG 2.2 Target Size criteria. Check buttons, links, form controls, and especially close buttons on modals. Small targets are difficult for users with motor impairments and frustrating for everyone on mobile.

Enable 'Reduce Motion' in your OS settings and verify that all animations either stop or use subtle fade transitions. Implement `@media (prefers-reduced-motion: reduce)` to disable parallax, auto-playing carousels, and large-scale animations. Motion can cause vestibular disorders.

Use semantic HTML elements (`<header>`, `<nav>`, `<main>`, `<aside>`, `<footer>`) or ARIA landmark roles. Screen reader users navigate by landmarks to jump between page sections. Every page should have exactly one `<main>` and at least a `<header>` and `<nav>`.

Use `<th>` with `scope='col'` or `scope='row'` for simple tables. For complex tables with merged cells, use `id` and `headers` attributes. Without proper header associations, screen readers announce table data as a flat list of values with no context.

Set `lang='en'` (or appropriate language) on the `<html>` element. If a section uses a different language, add `lang` to that element. Screen readers use the language attribute to switch pronunciation rules — without it, foreign text is read with English phonetics.

For every custom widget (tabs, accordions, comboboxes, tree views), verify it follows the keyboard interaction pattern defined in the WAI-ARIA Authoring Practices Guide. Users expect standard keyboard patterns — a custom tab that doesn't support arrow key navigation is broken for screen reader users.

Create a VPAT (Voluntary Product Accessibility Template) or internal accessibility report listing all known issues, their WCAG criteria, severity, and planned fix dates. This demonstrates due diligence and gives your team a prioritized roadmap for ongoing improvement.