Website accessibility audit: what it is and what you get

A website accessibility audit answers a specific question for a defined scope: how well does this site meet a named version and level of WCAG, and what has to change? The answer comes from testing, not from a score. W3C's overview of its evaluation methodology describes it as being "for anyone who wants a common procedure for auditing digital products, like websites", whether the work is done by your own staff or by an outside firm.

This guide explains the three kinds of testing an audit draws on, the five steps in W3C's methodology, how pages are sampled, what to prepare, what a useful report contains and how to judge an auditor. It also says what GotAlt's free scan, deep audit and monitoring cover, and what they leave to a person. Audit prices vary with scope, so we quote none; the section on judging an auditor lists what to ask for in writing.

Scan, expert audit and user testing: three kinds of testing

The three methods answer different questions, and a thorough audit uses all of them. W3C says evaluation tools can quickly identify potential problems and can help with manual review, but that they cannot check every aspect of accessibility automatically, that they sometimes give false or misleading results, and that a person's judgment is needed (Selecting Web Accessibility Evaluation Tools).

How much a scan can cover is a measured question, and the answers are modest. Karl Groves writes that an automated tool "can definitively test for approximately 25-29% of best practices for WCAG 2.0" and "cannot test for approximately 40%" (Automated Lies with One Line of Code). Sources disagree on the exact share, so treat roughly a third as an estimate, not a measurement. Our page on what automated testing can and cannot check in WCAG goes through it criterion by criterion.

User testing is optional in WCAG-EM but strongly recommended: the methodology says that, while not required, it is strongly recommended for evaluators to involve real people with a wide range of abilities. W3C's guidance on involving users in evaluating web accessibility says it finds usability issues that conformance evaluation alone does not, and also says it should be combined with checks against the standard rather than replace them.

The five steps of WCAG-EM

W3C's WCAG Evaluation Methodology is the reference procedure for auditing a site against WCAG. The Accessibility Guidelines Working Group published WCAG-EM 2.0 as a W3C Group Note on 23 July 2026, and version 1.0 remains available. A Group Note is endorsed by the working group but not by W3C itself, and it provides informative guidance: it adds no WCAG requirements. W3C's WCAG-EM overview also advises doing preliminary checks first and addressing potential accessibility barriers before investing in a more thorough review.

1. Define the scope

   Decide what the product is, which WCAG version and level is the target, and which browsers and assistive technologies the site must work with (the accessibility support baseline). Without a baseline, "it works" has no meaning.

2. Explore the product

   Identify the common views, the essential functionality, the types of page and content, and the technologies the site relies on. This is the inventory the sample is drawn from.

3. Select a representative sample

   Choose a structured sample that reflects everything found in step 2, add a random sample, and include every page of any complete process such as checkout.

4. Evaluate the sample

   Test the sample against the success criteria and check complete processes. Then compare the random sample with the structured one: it should show no new types of content and no new findings. If it does, the structured sample was not representative and step 3 repeats.

5. Report the findings

   Document the outcome of each step. Optional parts are the evaluation specifics, an evaluation statement, an aggregated score and a machine-readable report. W3C's WCAG-EM Report Tool helps structure the report; it does not do the checking.

How pages are sampled

Testing every page is the most thorough option, and W3C's overview treats sampling as the fallback for when it is not feasible to evaluate every view of a product. For the sample, WCAG-EM 2.0 asks for three things:

• A structured sample set. Samples that reflect all the common views, essential functionality, types of page, technologies and other relevant samples found in step 2. WCAG-EM sets no fixed page count. It says the size needed depends on factors such as the size, age and complexity of the product.
• A random sample set. The number of random samples is 10% of the structured set, added on top. W3C's own example is a structured set of 80, which adds 8 for 88 in total. Its purpose is a check: if the random pages turn up new kinds of content or new findings, the structured set missed something.
• Complete processes. Every page or view in a series that makes up a process, such as a purchase or a registration, so a barrier on step four of five is not missed.

For an online shop, a structured sample might include the home page, a category page, a product page, search results, the full cart and checkout path, sign-in and account pages, one page for each type of form, a long text page such as a policy, a downloadable document such as a PDF and the error page. That list is our illustration, not W3C's.

A sample has a built-in limit. W3C states that a sample alone cannot support a WCAG 2 conformance claim for a whole website, because unidentified errors are always possible on the pages not tested. An audit of a sample reports findings and documents its method; it does not certify the site.

What to prepare before an audit

The first two steps of WCAG-EM 2.0 show what an evaluator needs from you. Settle these before anyone quotes:

• The target. WCAG-EM calls WCAG 2 Level AA the generally accepted and recommended target. Name the WCAG version too.
• Your key journeys, such as sign-in, search and checkout. They feed the sample.
• Access. WCAG-EM says the evaluator needs access to all the relevant parts of the product, which may mean test accounts and realistic sample data.
• The support baseline. The browsers and assistive technologies your audience uses.
• Extras, in writing. Anything beyond the standard report, such as every occurrence of each failure or repair suggestions.

What a good audit report contains

W3C publishes a template for accessibility evaluation reports, and WCAG-EM sets out what its own reports should hold. Between them they describe a report you can check and act on.

We would add a few fields per issue that no standard demands but a developer needs: the URL or component, the steps to reproduce it, who it affects and a priority. Ask whether the report is a document, a spreadsheet or both, and whether you can export the findings into your tracker.

How to judge an auditor

The word audit covers very different work. These questions separate a method from a tool export with a cover page. We name no providers, because the questions are the point.

• Which method do you follow? A published one, such as WCAG-EM, means the scope, sample and report can be checked against a document. "Our proprietary process" means you cannot.
• Which WCAG version and level, and which browsers and assistive technologies? The answer should match the standard you are held to; see which WCAG version the law requires and what levels A, AA and AAA mean. A vague "we follow WCAG" is not an answer.
• How is the sample chosen, and can we add pages? You know your key journeys. A good auditor asks for them.
• Who does the testing? WCAG-EM assumes evaluators have a solid understanding of WCAG, accessible design, assistive technologies and how people with different disabilities use digital products. W3C notes that a single individual rarely has all of that expertise, and its guidance on using combined expertise describes how a team covers the gaps, including people with disabilities.
• What is automated, what is manual, and what is done with real assistive technology? A report that is only a tool export is a scan with a different cover.
• Do users with disabilities take part? Not required by WCAG-EM, but strongly recommended.
• What does each finding show? Look for the page or component, the criterion and how to reproduce it. WCAG-EM treats repair suggestions as an optional extra, so ask whether a fix comes with each finding. Ask for a sample finding before you sign.
• Is a retest included, and what does it cover? Fixes can be partial, so retest the failed items to confirm the work was done.
• What will you promise about the outcome? An auditor who guarantees legal protection, or a badge, is selling something an audit cannot deliver. The FTC's final order of 21 April 2025 required accessiBe to pay $1,000,000 over claims that its product would make a website meet WCAG, which the FTC said were false or unsubstantiated (FTC press release). Read what the FTC found about overlays before accepting a script as the fix.
• Are you independent of the team that built the site? Not a rule, but a reasonable thing to ask and to have recorded in the report.

After the audit: fix, retest, monitor

The report is the start of the work. Fix problems in shared templates and components first, because one change repairs many pages, then work through page-specific issues. Retest the failed items, not only the ones that were easy. Our guide to the most common accessibility errors shows which categories to expect to find and how to fix each.

WCAG-EM covers the retest. An evaluation may be re-run after the owner repairs issues, or periodically to monitor progress. The later sample keeps part of the earlier one, so the results can be compared, and replaces part of it to widen coverage; WCAG-EM says the replaced share is typically about half of the initial sample set.

Then keep watching. An audit describes a site on the days it was tested; a new template, a campaign page or an uploaded image changes it. W3C's report template asks for a plan for ongoing monitoring, and W3C's evaluation overview advises evaluating early and throughout development rather than once at the end.

What GotAlt's scan, deep audit and monitoring do and do not replace

GotAlt is not an audit firm, and nothing it produces is a WCAG-EM evaluation or a conformance statement. What it does is take the repeatable, machine-checkable part off the table so a person's time goes to the rest. Our methodology page lists every rule and every limit.

A proportionate path from there looks like this:

1. Scan and fix the cheap problems

   Run the free scan and the bookmarklet, then clear what they find. W3C advises addressing potential accessibility barriers before investing in a more thorough review.

2. Run the quick manual checks yourself

   Use the testing guide and the keyboard test, and work down the WCAG 2.2 checklist.

3. Commission a full evaluation when the stakes call for one

   A procurement request for an accessibility conformance report (see VPAT and ACR), a legal deadline such as the ADA Title II dates, a demand letter or a major relaunch are the usual triggers. Define the sample, the target and the baseline in writing.

4. Retest, then monitor

   Retest what failed, and use monitoring to catch regressions between audits.