A website accessibility audit is a structured test of a site against the Web Content Accessibility Guidelines, normally WCAG 2.2 at Level AA, that produces a report listing every failing success criterion, where it occurs, how severe it is and how to fix it. A real audit combines automated scanning with manual testing by a person using a keyboard and a screen reader, because scanners can only detect about a third of the criteria. The output is what a compliance officer, a procurement team or an attorney will ask to see, and it is the starting point for any remediation. This guide explains what a proper audit contains, how automated and manual testing differ, what the report should look like, what drives the price, and how to tell a real audit from a scan with a logo on it.

When you need an audit

  • You have received a demand letter or a complaint. The audit establishes what is actually wrong and becomes the basis of your response and remediation plan.
  • You are a public entity or a federally funded healthcare provider. The ADA Title II rule (deadlines April 26, 2027 and April 26, 2028) and the HHS Section 504 rule (May 11, 2027 and May 10, 2028) require WCAG 2.1 AA, and the audit is how you find out how far you are from it.
  • A customer or partner has asked for a VPAT or an accessibility conformance report. You cannot fill one in honestly without an audit behind it.
  • You are about to redesign. Auditing the old site tells you which failures are structural, so the new build avoids them, and gives you a baseline to prove improvement.
  • You have never checked. The ten-check self-test will tell you in half an hour whether you have obvious problems; the audit tells you everything.

Automated testing: fast, necessary, and not enough

Automated tools (axe, WAVE, Lighthouse, and the enterprise platforms built on the same engines) load a page, inspect the code and flag the failures that can be determined from code alone: missing alt attributes, contrast ratios below threshold, form fields with no label, empty links and buttons, duplicate IDs, missing page language, heading levels that skip. They are fast, repeatable and cheap, and every audit should start with them, run on every template rather than every page, because templates are where the code lives.

Their limit is that most of WCAG is about meaning and behavior, and code cannot judge either. A scanner sees that an image has alt text; it cannot tell that the alt text says “image1.jpg.” It sees a button; it cannot tell whether pressing Enter on it does anything. It cannot tell whether focus order makes sense, whether an error message helps, whether a custom menu works with a screen reader, whether captions are accurate, or whether a process can be completed at all. Estimates of automated coverage range from about 30 to 57 percent of issues depending on how you count; either way, a clean scan is a starting line, not a finish line.

A report that consists only of scanner output is not an audit. It is a scan. Several companies sell scans as audits, and the difference shows the first time someone with a screen reader tries to use the site.

Manual testing: what a person does that a tool cannot

Manual testing covers the rest of the standard. For each template and each multi-step process (contact, checkout, account creation, login, search, booking), an auditor does the following.

  • Keyboard-only pass. Every control reached and operated with Tab, Shift+Tab, Enter, Space, arrow keys and Escape. Focus visible throughout, in a sensible order, never trapped, never hidden behind a sticky header (WCAG 2.1.1, 2.1.2, 2.4.3, 2.4.7, 2.4.11).
  • Screen reader pass. The same templates and flows with at least one screen reader (NVDA or JAWS on Windows, VoiceOver on Mac and iOS, TalkBack on Android). Are headings, landmarks, labels, states and status messages announced correctly? Can the form be completed? Does the modal announce itself and return focus when closed? (1.3.1, 3.3.1 to 3.3.3, 4.1.2, 4.1.3)
  • Zoom and reflow. 200 percent zoom and a 320-pixel viewport, plus overridden text spacing (1.4.4, 1.4.10, 1.4.12).
  • Content review. Whether alt text is meaningful, links make sense out of context, instructions do not rely on color or position, captions are accurate, and PDFs are tagged (1.1.1, 1.3.3, 1.4.1, 2.4.4, 1.2.x).
  • Touch and pointer. Target sizes, dragging alternatives, hover content behavior, gesture alternatives (2.5.1, 2.5.7, 2.5.8, 1.4.13).
  • Timing, motion and media. Timeouts, carousels, autoplay, animation controls, flashing (2.2.1, 2.2.2, 2.3.1, 1.4.2).
  • Third-party components. Chat widgets, booking tools, payment forms, maps and embeds tested the same way, because a vendor’s failure is still your site’s failure.

A thorough manual pass of a typical business site takes a skilled auditor days, not hours, which is where the cost of a real audit comes from.

What the report should contain

Insist on all of these. If a proposal cannot promise them, it is not an audit.

  1. Scope. Which URLs, templates and processes were tested, with which browsers, screen readers and devices, on what dates, against which WCAG version and level.
  2. A finding for every failure, each with the success criterion number, the location (URL and element), a description, a screenshot or code excerpt, a severity rating, and a recommended fix. Findings should be grouped so that one template-level failure appearing on 400 pages is one finding, not 400.
  3. A severity model. At minimum: blocks a task, seriously impairs a task, causes friction, best practice. This is what turns a list into a plan.
  4. A conformance summary by success criterion: pass, fail, not applicable, for all 55 Level A and AA criteria. This is the table a VPAT or an accessibility conformance report is built from.
  5. A remediation roadmap that separates content fixes (your team, this week), code fixes (a developer, scoped) and structural problems (the theme or platform itself), with an honest view of whether the site can be fixed or should be rebuilt.
  6. A re-test. After remediation, the failures are re-tested and the report is updated. An audit that ends at the report leaves you with a document, not a compliant site.

What drives the cost

Audit prices vary by an order of magnitude, and the spread comes from scope and depth rather than from the auditor’s rate card.

  • Number of templates and processes. A brochure site with five templates and one form is a small job. An e-commerce site with a filtered catalog, checkout, accounts and a help center is not. Page count matters far less than template count.
  • Depth of manual testing. One screen reader on a desktop, or three screen readers across desktop and mobile? Automated-only reports are cheap because they skip this entirely, and that is exactly why they are not worth much.
  • Complexity of components. Custom-built interactive components (configurators, dashboards, maps, calculators, media players) each need dedicated testing.
  • Third-party and document scope. Auditing embedded vendor tools and a PDF library adds time.
  • Deliverables. A findings list is quicker than a full conformance report; a VPAT or ACR is an additional deliverable with its own format.
  • Remediation and re-testing. Some quotes stop at the report. Ours include the code fixes when we build or maintain the site, and a re-test either way.

We scope audits after a discovery call and quote them as a fixed price, so the number covers the templates and flows that actually exist rather than a per-page rate that rewards nobody. If a site was built on a page builder or a template that was never accessible, we will say so at the audit stage rather than sell remediation that cannot succeed; our website cost guide covers what a rebuild involves.

Audit, then what?

Findings fall into three piles. Content (alt text, captions, link text, PDFs, contrast on specific images): your team fixes these with the ADA compliance checklist in hand. Code (labels, focus, keyboard support, component semantics, heading structure): a developer fixes these in the theme, and on a hand-coded site they are usually a contained project. Structural (the platform itself generates inaccessible markup, or every component fights the fix): this is the rebuild conversation, and it is better to have it early. For The Trust Company of North Carolina, the answer was a custom theme with WCAG AA built in and then verified by independent third-party audit tooling, which is the difference between claiming conformance and being able to demonstrate it to a regulator.

After remediation: re-test, publish an accessibility statement that names the standard and gives people a way to report barriers, add the content checklist to your publishing process, and re-audit after any redesign or at least annually.

How to tell a real audit from a scan

  • It names the screen readers and browsers used, and the person who used them.
  • It reports by success criterion, with locations, not by “issues found” count.
  • It includes findings a scanner cannot produce: focus order, meaningful alt text, form completion with a screen reader, modal behavior.
  • It tests processes end to end, not just landing pages.
  • It does not recommend an overlay. Overlays do not fix code, they interfere with assistive technology, and sites running them have been sued. Any auditor who suggests one as a remedy has told you what kind of audit you bought.
  • It includes a re-test.

Frequently asked questions

How long does a website accessibility audit take?

For a typical business site with five to ten templates and a few forms, expect one to two weeks from kickoff to report, most of it manual testing. Large applications take longer. Automated-only scans take minutes, which is a fair indication of what they cover.

What is the difference between an accessibility audit and a VPAT?

An audit is the testing. A VPAT (Voluntary Product Accessibility Template) is a document format, published by the Information Technology Industry Council, for reporting the results criterion by criterion; a completed VPAT is called an Accessibility Conformance Report. Buyers, especially government and enterprise, ask vendors for a VPAT. It has to be based on a real audit to be worth anything.

Can I audit my own site?

You can get a long way: run WAVE or axe on every template, then do the keyboard and screen reader checks in our ten-check self-test. What you will lack is coverage of the full criteria list and an independent report, which matter if you face a legal claim, a procurement requirement or a regulatory deadline.

Is an accessibility audit legally required?

No law requires the audit itself; the laws require the result. But an audit is the only way to know whether you meet WCAG 2.1 AA, and a documented audit and remediation history is the strongest evidence of good faith if a complaint arrives.

Do you audit sites you did not build?

Yes. Most audits are of sites we did not build. The report tells you what is wrong regardless of who fixes it, and we will tell you plainly if the answer is that the platform cannot be made conformant.

Get an audit you can hand to a lawyer

Our ADA compliance services audit every template and process against WCAG 2.2 AA with automated and manual testing, report by success criterion with severity and fix, remediate in the code, and re-test.

Book a Discovery Call →

or call 919-200-0201