How to Check Website ADA Compliance: A Practical First Pass

Start with a useful question

If you are asking how to check whether your website is ADA compliant, begin by finding and documenting accessibility barriers. This first pass helps you decide what to repair and test next; it cannot issue a compliance determination.

Pick a task that matters to your visitors: finding a service, asking a question, booking an appointment or completing a purchase. List the pages and states involved, including errors and confirmation. Use a test environment and synthetic inputs when a successful action could send a message, book something or charge a payment method.

Record the page URL, date, site revision if available, browser, viewport and test method. Decide the WCAG version and level for the broader evaluation separately. Our audit-scope guide helps define that coverage; this page explains how to begin checking it.

1. Run an HTML scan and read its scope

Open the free accessibility HTML scanner, enter a public page URL without credentials or sensitive query parameters, and select Scan public HTML. The URL is sent to our server to fetch the page. Optional linked-page mode checks the starting page and up to four same-origin links; it is not a complete site crawl.

The scanner runs selected axe-core rules tagged for WCAG 2.0 and 2.1 A/AA against fetched HTML. It can identify issues such as missing accessible names, form labels or document language. It does not execute the site's scripts, render its layout, measure color contrast or inspect authenticated pages and completed processes. A fetch error means the page was not scanned.

Save the findings and the scope. A rule count is not a percentage of compliance, and several instances may share one underlying repair. Inspect each result in context before assigning a fix. W3C explains why evaluation tools require human judgment.

Completed example: zero findings on our contact page

On October 19, 2026 at 20:58:54 UTC, we ran the live scanner against our public contact page. Linked-page mode was off. The displayed result was:

• Fetched HTML elements: 388.
• Rules with findings: 0.
• Reported instances: 0.
• Keyboard focus after the scan: HTML scan results heading.

The site revision was 8ba239a. We saved the browser observation and source-scope record (JSON). It records the displayed output, not a downloaded raw scanner report or a screen-reader transcript.

This scan happened after our contact-form instruction repair. It does not show what the scanner would have found before that repair. It also does not demonstrate successful submission, message delivery, error announcements or usable contrast.

Our separate contact-form review used actual browser interactions with synthetic inputs. It recorded four errors after an empty attempt, focus moving to Name, later correction states and the addition of an upfront message-length instruction. Those observations answer questions that this HTML-only scan did not exercise. We deliberately avoided sending a valid enquiry; successful delivery and screen-reader behavior on that form remain untested.

The practical lesson is to keep these records alongside each other. “No automated findings” and “this interaction has not been tested” can both be true.

2. Walk through the task with a keyboard

Use Tab and Shift+Tab to move among controls, Enter or Space where appropriate to activate them, and the expected arrow-key commands within composite widgets such as tab lists. Not every item inside a widget needs its own Tab stop.

Check whether you can see focus, understand its order, operate the controls and return from opened content. A modal normally keeps focus inside while open; the problem is being unable to close or leave it using the expected keyboard interaction. Include the error and correction path, not just arrival at the form.

Our completed heading-validator keyboard example records page entry, input, validation, result-heading focus, return to the input, correction and reaching the download control. The download was reached but not activated. That is the boundary of the result, not evidence of a successful download.

If you cannot complete a step, record the key sequence, current focus and visible result. Reproduce it before concluding what caused it. Do not extrapolate one tester's difficulty to every keyboard or switch user.

3. Test screen-reader output separately

A screen reader has reading/navigation commands as well as controls for interacting with forms. Reading position and keyboard focus are related but are not always the same. Learn the chosen screen reader's modes and record the version, browser, operating system and exact commands used.

For a first task, inspect headings and control names, enter input, trigger an error, correct it and check the result. Record what was announced automatically separately from what you found using reading commands. A label or live-region attribute in the code is not proof that the intended message was spoken.

We completed a real NVDA heading-validator session on Windows with Chromium. Captured application speech named the results heading automatically; reading commands exposed the counts. After reading those results, the recorded path back to the input differed from our direct keyboard-only path. The workflow includes the exact environment and retained speech log.

That evidence covers the tested tool and journey. It is not a VoiceOver test, a contact-form test, an audio recording or a study with disabled participants. A brief first-time screen-reader exercise is not a substitute for experienced assistive-technology evaluation or user research.

4. Check content and visual states in context

Review meaningful images, link purpose, headings and field instructions on the actual page. Alternative text should serve the image's purpose in context; decorative images need different treatment from informative images or image links. Our heading validator reviews supplied heading entries, not a complete rendered page or the quality of every heading's wording.

For contrast, identify the actual foreground and background in each relevant state before entering colors into the contrast checker. Gradients, transparency, text over images and hover/focus/error states need context that a single opaque color pair cannot supply.

Our tested contrast examples include a useful boundary: #707972 on white calculates to about 4.499795:1. The display rounds to 4.50:1, but the unrounded value is below the 4.5:1 normal-text AA threshold. We verified six supplied color pairs; we did not establish whole-page contrast from them.

Also check enlargement. Text resizing to 200% and reflow are separate requirements. For vertically scrolling content, test the equivalent of a 320 CSS-pixel-wide viewport; 400% zoom from a 1280 CSS-pixel-wide viewport is a common setup. Check for lost content or functionality and unnecessary scrolling in both directions. Parts that require a two-dimensional layout have an exception; that is not a blanket exemption for the page.

These are checks to perform on your site. They are not additional tests we claim to have completed during the single-page scan above.

5. Turn observations into a repair and retest

Use the blank self-check record (CSV) to retain each method separately. Include what you expected, what actually happened, the evidence location, the responsible person and the retest revision. Use not tested for missing evidence; do not count it as passed.

Prioritize a barrier's effect on completing the task, its reach across reused components and the confidence of the diagnosis. Agreement between scanners is not a substitute for that judgment. A repeated missing label may have one shared-component fix; an unreported interaction can still block the task.

After repair, repeat the same steps and inputs, then check the released version. Our audit-process worked example shows how an actual parser finding became a repair and repeatable evidence. Its finding concerns the tool's output; it is not presented as a complete WCAG assessment.

For a broader review, expand coverage to the important templates, processes, states and technologies in the agreed scope. W3C's Easy Checks is another starting resource. Keep unsupported conclusions out of an accessibility statement, and use the DIY work plan to organize the next bounded session.