Most WCAG compliance audits are bought on price and judged on a score. Both are the wrong measures. The price depends on what was sampled, which most quotes never state. The score depends on what was tested, and a large part of WCAG cannot be tested by a machine at all.
That last point is measurable. The UK Government Digital Service built a single web page containing 143 deliberate accessibility barriers, then ran ten automated tools over it.
So an audit that is mostly a scan will miss problems a disabled user meets on day one. This guide covers what a real audit tests, which rules apply to you, the method to insist on, how scoping drives cost, what a usable report looks like, and what to do after it.
What a WCAG audit has to cover in 2027
The current standard is WCAG 2.2, first published as a W3C Recommendation on 5 October 2023 and last updated in December
- Most laws and contracts ask for Level AA, so that is the scope to buy.
Why 2.2 rather than 2.1
The specification is explicit: "Content that conforms to WCAG 2.2 also conforms to WCAG 2.0 and WCAG 2.1." Auditing to 2.2 AA therefore satisfies a 2.1 or 2.0 requirement as well, with one caveat. Criterion 4.1.1 Parsing was removed in 2.2, so if a contract or regulation names 2.0 or 2.1, ask the auditor to test and report 4.1.1 separately.
The six criteria older audits never checked
An audit run to WCAG 2.1 tests none of the six new Level A and AA criteria. Two of them matter more than the rest for most products. Target Size (Minimum), 2.5.8, catches controls too small to hit reliably. Accessible Authentication (Minimum), 3.3.8, catches login steps that depend on remembering or transcribing something, such as some puzzle checks.
If your last audit predates 2.2, it is not a baseline for 2027. It is a baseline for a standard that has moved.
Which rules apply to you
"Who needs to be WCAG compliant?" has no single answer, because WCAG is a technical standard, not a law. Laws adopt it, each in its own version and with its own dates.
US state and local government
The Department of Justice's Title II web rule names WCAG 2.1 Level AA for web content and mobile apps. The original deadlines were moved by an Interim Final Rule published on 20 April 2026. Governments serving 50,000 or more people now have until 26 April 2027, and smaller ones and special district governments until 26 April 2028. Many pages still quote the 2026 date; it no longer applies.
US businesses
For businesses open to the public, the DOJ's web guidance says the department "does not have a regulation setting out detailed standards". Businesses "have flexibility in how they comply", but the ADA's general duties still apply. In practice WCAG AA is the benchmark used to judge whether a site is accessible, which is why it is the scope worth auditing to.
US federal agencies and their suppliers
Section 508's revised standards require electronic content to conform to WCAG 2.0 Levels A and AA, and have applied since 18 January 2018. Suppliers are usually asked for an Accessibility Conformance Report, covered below.
The European Union
The European Accessibility Act applies from 28 June 2025 to a defined set of products and services, including e-commerce. The directive exempts microenterprises providing services. If you sell into the EU, confirm with counsel which of your services fall in scope before scoping the audit.
None of this is legal advice. It is the reason one well-scoped audit to WCAG 2.2 AA usually serves several regimes at once.
Where most sites actually fail
Before paying for an audit, it helps to know what it will almost certainly find. WebAIM scans the home pages of the top one million websites every year.
What that means for your budget
These six error types are cheap for an auditor to find and cheap for you to fix. If you pay for a manual audit before fixing them, you pay expert rates to be told your contrast is low. Run a free automated checker first, fix what it reports, then buy human time for what machines cannot judge.
Our comparison of accessibility testing tools covers which scanners are worth running for that first pass.
The method to insist on: WCAG-EM
The W3C publishes its own method for evaluating a site against WCAG, the WCAG Evaluation Methodology. Version 2.0 was published as a W3C Group Note in July 2026. It is not mandatory, but it is the closest thing the field has to a shared procedure.
Why the method matters more than the tool list
Two audits of the same site can disagree because they sampled different pages, not because either auditor was wrong. WCAG-EM fixes that by making the sample explicit and adding a random sample to test whether the chosen pages are representative. An audit you cannot repeat is an audit you cannot use to prove progress.
WCAG-EM also states what it is not: it "does not replace the need for quality assurance throughout all phases of product development". An audit is a measurement. It does not make the next release accessible on its own.
Scoping the audit, and why it decides the price
"How much does a WCAG audit cost?" is the most common question, and the honest answer is that it depends on the sample, not the size of the site. Here is the arithmetic on an illustrative online store.
What drives the effort
- Templates, not URLs. A thousand product pages built from one template are one template to audit, plus spot checks.
- Processes. Every step of every flow that a user must complete, because of the complete-process rule below.
- Distinct components. A custom date picker or video player needs its own careful testing, wherever it appears.
- Platforms. Web only, or web plus iOS and Android apps. Each platform is a separate evaluation.
- Assistive technology coverage. Which screen readers, with which browsers. More combinations mean more hours.
How to compare quotes honestly
Ask every provider for three things before comparing prices: the list of pages and flows they will test, the WCAG version and level, and the assistive technology and browser combinations. Two quotes with different sample lists are not comparable, however similar the totals look.
We do not publish price ranges here, because any figure without your sample list would be invented. The useful number is verdicts: pages in the sample multiplied by 55 criteria. That tells you how much work you are actually buying.
Test processes end to end, not page by page
This is the rule most often missed when audits are scoped by URL list. WCAG 2.2 sets five conformance requirements, and two of them change how a site has to be sampled.
Full pages
Conformance requirement 5.2.2 says conformance "cannot be achieved if part of a web page is excluded". You cannot exclude a third-party chat widget or cookie banner and call the page conformant. WCAG offers a Statement of Partial Conformance for third-party content you cannot control, but that is a disclosure, not a pass.
Complete processes
Requirement 5.2.3 states that if any page in a process fails, the process fails at that level. The specification's own example is an online store, from product selection to checkout. So sample processes in full: sign-up, login, checkout, password reset, and any form that ends in a submission that matters.
Responsive layouts, apps, documents and third parties
Most quotes are written for "the website" as it looks on the auditor's laptop. Four kinds of content routinely fall outside that, and each one is somewhere users get stuck.
Every screen size is part of the page
WCAG 2.2 adds a note to the full-pages requirement: a full page "includes each variation of the page that is automatically presented by the page for various screen sizes". A responsive site that conforms at desktop width but hides its menu behind an unlabelled icon on a phone does not conform. Ask the auditor which viewport widths they test, and expect at least a phone width and a desktop width for every sampled page.
Mobile apps are a separate evaluation
WCAG was written for web content, but regulators apply it to apps too: the DOJ's Title II rule names WCAG 2.1 AA for state and local government mobile apps as well as websites. An app audit is a different job from a web audit. It uses the platform screen readers, VoiceOver on iOS and TalkBack on Android, along with platform text-size settings and switch access. Price and schedule it separately, and check that the provider names the devices and operating system versions.
Documents behind the links
PDFs, slide decks and spreadsheets linked from a page are content your users need. They are tested against different techniques from HTML pages, and they are often where public-sector sites fail. Decide at scoping time which documents are in the sample: the forms people must complete, and anything published since the last audit, are the usual priorities.
Third-party components
Chat widgets, payment frames, cookie banners, embedded maps and booking tools sit on your pages, so they affect your conformance. Ask each vendor for its Accessibility Conformance Report. Where a component fails and you cannot change it, WCAG's Statement of Partial Conformance lets you disclose that honestly. The better long-term answer is to make accessibility a requirement in the next renewal.
How to test a website for WCAG compliance
A credible audit combines four kinds of testing. Each catches what the others miss.
Testing with disabled users
Expert testing finds conformance failures. Testing with people who use assistive technology every day finds usability failures that still pass the criteria. If the product serves a large disabled audience, budget for both. They answer different questions.
What the report should contain
The report is the only thing you keep from an audit. A score on its own tells your developers nothing they can act on. Every finding should look like this.
Severity is a judgement, so the scale must be written down
WCAG levels do not tell you what to fix first. A Level AA failure in the payment step matters more than a Level A failure on an archived news page. A useful report ranks findings on a scale it defines in writing:
Ask how severity was assigned. If the answer is "the tool decides", the ranking reflects what was easy to detect, not what hurts users.
The summary should answer three questions
- Does the sample conform to WCAG 2.2 AA? Yes or no, with the count of failing criteria.
- Which complete processes are blocked? These are the failures that stop a user finishing a task, so they come first.
- What was tested, and how? The sample list, the method, the tools, and the assistive technology combinations, so the audit can be repeated.
Accessibility Conformance Reports
If you sell to the US government or to large enterprises, buyers will ask for an Accessibility Conformance Report. ITI's VPAT template, now at version 2.5Rev, comes in WCAG, 508, EU and international editions. ITI describes the completed template, with documented testing results, as an ACR. An audit report and an ACR are different documents: the audit tells your team what to fix, the ACR tells your buyers where you stand. A good audit gives you the evidence to write an honest ACR.
Questions that separate a real audit from a scan
Is there a certification for WCAG compliance?
Not from the standard's authors. WCAG 2.2 defines conformance requirements and treats conformance claims as optional, made by the site owner. Some providers issue their own certificates or badges. Read those as a statement by that provider, and ask what sample and date it covers. A badge cannot show that the next release still conforms.
Common mistakes buyers make
- Buying a scan and calling it an audit. The GOV.UK test above shows how much is left out.
- Auditing to WCAG 2.1 in 2027. Six A and AA criteria go untested.
- Scoping by URL count. It inflates cost on large template sites and under-tests small sites with complex flows.
- Leaving out the logged-in area. Accounts, dashboards and checkout are where users complete tasks, and where processes fail.
- Skipping the retest. A fix that has not been verified is a hope.
- Treating the audit as the end. Conformance decays with each release.
After the audit
The report gives you a baseline. Keeping conformance is a process, and it starts the week the report lands.
Fix in the right order
Start with blockers inside complete processes, because they stop users finishing tasks. Then fix by reach: issues in shared templates and components fix many pages at once. Leave single-page cosmetic findings for last.
Stop the regressions
Put an automated accessibility check into your CI pipeline so the six common error types cannot come back unnoticed. It will not catch everything, as the tools study shows, but it stops the cheapest failures returning. Our WCAG 2.2 test case library gives your team checks to run by hand between audits.
For a wider view of the testing that sits around an audit, our website accessibility testing guide covers the day-to-day practice.
A buying sequence that works
- Run a free automated checker and fix the obvious errors first
- List your templates, processes and distinct components
- Decide the standard: WCAG 2.2 AA, plus 4.1.1 if a policy needs it
- Ask three providers for their sample list, method and assistive technology set
- Compare quotes only on matching sample lists
- Insist on findings with all eight fields and a retest
- Put automated checks into CI and plan the next audit before this one ends
Steps 2 and 4 decide whether the audit you buy is comparable, repeatable and worth its price.
Getting an audit scoped properly
If you want a sample list before you commit to anything, QAble's accessibility audit service starts with exactly that: the templates, processes and assistive technologies to be tested, against WCAG 2.2 AA.