Is My Website ADA Compliant? How to Check

Automated tools are valuable because they inspect code consistently and at scale. They can flag missing image alternatives, unlabeled controls, invalid accessibility attributes, some contrast problems, and other machine-testable failures. But they cannot decide whether alt text communicates the right meaning, whether instructions are understandable, or whether a complete booking or checkout experience works well with assistive technology.

The DOJ warns that a clean automated report does not necessarily mean everything is accessible. WCAG conformance also applies to full pages and complete processes, not just isolated components. Use a scanner to learn where to look, then verify the experience manually.

Start with the homepage and the pages tied to a customer outcome: contact, booking, menu, product, cart, checkout, account creation, and support. Include one example of each major template. A ten-page sample chosen by business importance usually teaches you more than scanning hundreds of low-traffic URLs without a plan.

Record each issue with its page, severity, affected component, and WCAG reference. Group repeated findings by root cause. Fixing one navigation component or form-field component may remove the same barrier from dozens of pages.

Complete the same important customer task during every check. For example, find a product, add it to the cart, correct an invalid field, and reach the order-review step. Do not submit a real order unless you control the test environment.

• Keyboard: Navigate forward and backward without a mouse. Confirm focus is visible, the order makes sense, menus open and close, and nothing traps focus.
• Zoom and reflow: Test at 200% zoom and a narrow viewport. Text and controls should remain available without overlapping or disappearing.
• Screen reader: Listen to the page title, landmark regions, headings, links, buttons, form labels, instructions, status updates, and errors.
• Visual review: Check contrast, text over images, meaning conveyed only by color, flashing content, and controls with small or unclear targets.
• Content review: Make link text descriptive, headings meaningful, instructions specific, and image alternatives appropriate to each image’s purpose.

WCAG 2.2 is the W3C’s current Recommendation and contains testable success criteria at Levels A, AA, and AAA. W3C advises using WCAG 2.2 when developing or updating accessibility policies because it includes additional criteria for focus visibility, dragging alternatives, target size, consistent help, redundant entry, and accessible authentication.

For most business improvement programs, Levels A and AA provide a practical technical baseline. That does not turn WCAG into individualized legal advice, and local requirements may differ. It gives your team a shared, testable language for finding and correcting barriers.

Fix anything that prevents a visitor from completing a core action first. Common examples include a menu that cannot be opened by keyboard, an unnamed checkout button, a form error that is shown only in red, or a dialog that traps a screen-reader user. Next, address high-frequency shared issues and then isolated content defects.

Retest the exact task after remediation. A code change can clear one automated rule while introducing another usability problem, so closing a ticket should require evidence that the user journey works—not just that a warning disappeared.

Keep a simple accessibility log: what was tested, the date, the pages and tools used, who reviewed it, barriers found, fixes completed, and items still open. Provide a public contact method for accessibility problems and a practical alternative when someone cannot complete a task.

Websites evolve. New content, third-party widgets, theme updates, and marketing experiments can reintroduce barriers. Recurring monitoring helps catch technical regressions early, while scheduled manual testing protects the full customer experience.