Blog

WCAG Audits in 2026: WCAG-EM Methodology, Tooling, and Four Sample Findings

TestParty
TestParty
September 21, 2026

Last updated: September 21, 2026

A formal WCAG audit is a conformance evaluation: every applicable success criterion, tested under a defined methodology against a representative sample of pages, producing findings a third party can rely on. That is what separates it from a scan or an internal spot-check. This page covers the methodology, the tooling and its limits, four sample findings written the way a real report writes them, and when this tier is worth commissioning.

Key numbers: WCAG 2.2 defines 86 success criteria, 55 of them at Levels A and AA β€” the set a conformance audit evaluates on every sampled page (W3C). W3C's WCAG-EM 2.0 methodology, a Group Note published July 23, 2026, defines five steps and adds a random sample equal to 10% of the structured sample. Automated tooling detects roughly 60–70% of issues in TestParty's audit work; the other 30% requires expert manual testing. Full manual WCAG 2.2 AA audits run roughly $3,000–$15,000+ for a mid-size ecommerce site and $10,000–$25,000+ at enterprise scope (published agency rates as of August 2026).

What makes a WCAG audit different from a scan or a self-check?

A WCAG audit evaluates every applicable success criterion under a documented methodology and produces a conformance answer someone else can rely on. A scan tests the machine-checkable minority of criteria; a self-check tests whatever the tester thought to try.

Three properties define the tier. Completeness: all 55 Level A and AA criteria are assessed on each sampled page and recorded as passed, failed, not applicable, or not checked β€” the passes included, because a conformance claim is a statement about the whole set. Method transparency: scope, sample, standard version, tool and assistive-technology matrix, and tester credentials are agreed before testing and restated in the report. Reliance: the output is written for a procurement reviewer, an ACR signer, or opposing counsel. For the wider landscape, see our reference on accessibility audits.

What methodology does a formal WCAG audit follow?

Credible auditors follow WCAG-EM, W3C's Website Accessibility Conformance Evaluation Methodology; version 2.0 extends it beyond websites to apps and other digital products. Its five steps:

  1. Define the evaluation scope β€” product boundary, conformance target (WCAG 2.2 Level AA for most commercial sites), and the browsers and assistive technologies relied upon.
  2. Explore the target product β€” common views, essential functionality, content types, and technologies, including third-party scripts you do not control.
  3. Select a representative sample β€” templates and states, a random sample equal to 10% of that structured set, and every page in a complete process.
  4. Evaluate the sample β€” assess each applicable criterion, verify complete processes end to end, and use the random sample to test whether the structured one missed a failure class.
  5. Report the findings β€” scope, method, and every outcome, with an optional conformance statement.

The random sample is the step buyers overlook and the one that makes a result defensible: it controls for the auditor's own scoping judgment. Sampling counts templates and states, not pages, and a store's sample is incomplete without the full cart-to-confirmation process. Third-party surfaces are tested and reported even where you cannot fix them, because they affect the user and therefore the claim: in TestParty's monthly expert audits of ecommerce stores, app-injected markup is a recurring source of blockers theme-only testing never sees.

What tools does a WCAG audit use, and where do they stop?

The stack has two layers: an automated pass across the full sample, then a manual pass on a documented matrix of screen readers and browsers. The first is fast and shallow; the second decides the outcome.

The automated pass runs a rules engine such as axe-core, cross-checked with WAVE and Lighthouse, over every sampled page and state. It catches contrast ratios, missing alt attributes, unlabeled inputs, and empty links and buttons β€” but cannot judge meaning, since `alt="IMG_4471"` passes every rule in every engine. That ceiling is why automation covers roughly 60–70% of issues in TestParty's work across 100+ brands, and why blockers concentrate in the other 30%.

+-------------------+---------------------+----------------+------------------------------------------+
|   Screen reader   |       Browser       |    Platform    |        What the pairing verifies         |
+-------------------+---------------------+----------------+------------------------------------------+
|        NVDA       |   Chrome, Firefox   |    Windows     |    Reading order, names, live regions    |
+-------------------+---------------------+----------------+------------------------------------------+
|        JAWS       |     Chrome, Edge    |    Windows     |    Forms mode, tables, virtual cursor    |
+-------------------+---------------------+----------------+------------------------------------------+
|     VoiceOver     |        Safari       |   macOS, iOS   |   Rotor navigation, mobile focus order   |
+-------------------+---------------------+----------------+------------------------------------------+

The matrix follows real usage: JAWS is the primary screen reader for 40.5% of users, NVDA 37.7%, and VoiceOver 9.7% (WebAIM Screen Reader User Survey #10). Keyboard traversal, 200–400% zoom, and cognitive walkthroughs run alongside.

What do WCAG audit findings look like?

Each finding is a self-contained record: ID, criterion and level, severity, location, description, user impact, evidence method, and a fix specification a developer can implement directly. Four examples follow.

F-014 β€” Sale price fails contrast minimum (1.4.3 Contrast (Minimum), Level AA)

  • Severity: Major
  • Location: Product detail template, discounted and compare-at price (`.price--on-sale .price-item`)
  • Description: Price renders as #9B9B9B on #FFFFFF at 16px regular weight β€” approximately 2.8:1. Normal-size text requires 4.5:1 (W3C Understanding 1.4.3); the 3:1 large-text allowance does not apply below 24px, or 18.66px bold.
  • User impact: Shoppers with low vision or reduced contrast sensitivity cannot read the price they are being charged; on mobile in daylight it affects users with no impairment.
  • Evidence method: axe-core color-contrast rule, confirmed with a contrast analyzer against computed styles at 200% zoom.
  • Fix specification: Set the price color token to #767676 (4.54:1) minimum, #595959 (7:1) preferred, at token level so every price component inherits it. Heavier font-weight does not change the required ratio.

F-021 β€” Newsletter modal traps keyboard focus (2.1.2 No Keyboard Trap, Level A)

  • Severity: Blocker
  • Location: `#newsletter-popup`, on 15-second delay and exit intent across home and collection templates
  • Description: On open, a focus-loop script confines Tab and Shift+Tab to the dialog. Escape is unbound, and the dismiss control is a `<div class="modal-close">` with a click handler only, so it never takes focus. No keyboard path out exists.
  • User impact: Keyboard-only and screen-reader users are stranded; browsing, cart, and checkout are unreachable until the session is abandoned. Highest-risk finding in this audit.
  • Evidence method: Manual keyboard traversal in Chrome and Firefox on Windows, confirmed with NVDA. No automated rule detects this class of trap.
  • Fix specification: Apply the standard dialog pattern β€” `role="dialog"`, `aria-modal="true"`, `aria-labelledby` on the heading; move focus into the dialog on open; bind Escape to close; return focus to the trigger; replace the `<div>` with `<button type="button">Close</button>`. Constraining focus inside an open modal is permitted; offering no keyboard exit is not.

F-033 β€” Cart drawer icon buttons have no accessible name (4.1.2 Name, Role, Value, Level A)

  • Severity: Critical
  • Location: Cart drawer β€” remove-item control (`button.cart-remove`) and quantity steppers
  • Description: Each control holds only an inline SVG with no text content, `aria-label`, or `aria-labelledby`; NVDA announces "button, button, button."
  • User impact: A screen-reader user cannot tell which button removes which line item, or which stepper belongs to which product. Editing a cart becomes guesswork immediately before payment.
  • Evidence method: NVDA + Chrome and VoiceOver + Safari; accessible-name computation inspected in the accessibility tree; partially flagged by axe-core `button-name`.
  • Fix specification: Name each control with its product β€” `<button type="button" aria-label="Remove Merino Crew Sock, size M, from cart">` β€” and mark the SVG `aria-hidden="true" focusable="false"`. Label steppers "Increase/Decrease quantity for [product]." Announce the new subtotal in an `aria-live="polite"` region, which also addresses 4.1.3 Status Messages (Level AA).

F-047 β€” Checkout address fields use placeholders as labels (3.3.2 Labels or Instructions, Level A)

  • Severity: Major
  • Location: Checkout, shipping-address step: address line 1, apartment/suite, postal code
  • Description: Fields render as `<input placeholder="Postal code">` with no associated `<label>`, so the only indication of purpose disappears on first keystroke. Automated label rules report a pass, because placeholder text is a fallback in the accessible-name computation β€” logged here as a documented false pass.
  • User impact: Users with cognitive and memory-related disabilities lose the field's purpose while typing, and magnification users see a column of unlabeled boxes. Error correction at the payment step becomes trial and error.
  • Evidence method: Accessibility-tree inspection, keyboard entry with NVDA in forms mode, and a 400% zoom pass; automated tooling did not flag it.
  • Fix specification: Add a persistent visible `<label for="…">` above each input and restrict placeholders to format examples. Add `autocomplete="address-line1"`, `address-line2`, and `postal-code`, satisfying 1.3.5 Identify Input Purpose (Level AA). Where checkout markup is platform-controlled, log the finding against the platform and record it in the claim's scope notes.

What does a complete WCAG audit report contain beyond findings?

Four elements separate a conformance-grade report from a findings list:

  • Executive summary β€” conformance status, counts by severity, and the top risks in language a non-technical stakeholder can act on.
  • Conformance claim scope β€” which URLs, which date, which technologies relied upon, and which third-party content is excluded or claimed only in part.
  • Methodology statement β€” the WCAG-EM steps as executed, the sample, the assistive-technology matrix, tool versions, and tester credentials. Without it, no reviewer can weigh the result.
  • Retest plan β€” the verification window and what counts as closed.

That package is the raw material for a VPAT and Accessibility Conformance Report when procurement asks.

When do you need a formal WCAG audit rather than a lighter one?

Commission the formal tier when someone outside your team will act on the answer: procurement, a regulator, opposing counsel, or a board approving a budget.

+------------------------------------------+----------------------------------------------------+----------------------------------------------------+----------------------------------------+
|                 Trigger                  |                Why the formal tier                 |  Typical cost (published agency rates, Aug 2026)   |                Timeline                |
+------------------------------------------+----------------------------------------------------+----------------------------------------------------+----------------------------------------+
|     Procurement or VPAT/ACR request      |           An ACR needs testing behind it           | $3,000–$15,000+, plus $350–$1,000 per ACR edition  |   2–6 weeks, plus a week for the ACR   |
+------------------------------------------+----------------------------------------------------+----------------------------------------------------+----------------------------------------+
|      EAA / EN 301 549 market entry       | Penalties run per member state, up to €500,000 (varies) |      $5,000–$25,000+ at multi-property scope       |               3–8 weeks                |
+------------------------------------------+----------------------------------------------------+----------------------------------------------------+----------------------------------------+
|   Active litigation or a demand letter   |     Counsel needs a dated, independent record      |        $3,000–$15,000+, with a rush premium        |          1–3 weeks expedited           |
+------------------------------------------+----------------------------------------------------+----------------------------------------------------+----------------------------------------+
|    Baseline before major remediation     |   Budget and sequencing depend on the whole set    |                  $3,000–$15,000+                   |               2–6 weeks                |
+------------------------------------------+----------------------------------------------------+----------------------------------------------------+----------------------------------------+

Otherwise a hybrid audit at roughly $1,000–$5,000 (published agency rates as of August 2026) surfaces blockers for far less; the 50-point technical remediation checklist is the working version of that path.

What happens after the audit?

Findings become tickets, blockers on revenue paths get fixed first, and the auditor re-evaluates the same sample to turn "reported" into "closed." An audit with no retest is a snapshot, not a program.

The failure pattern is consistent: reports land, findings sit while sprints fill with revenue work, and the site drifts until what ships no longer resembles what was audited. TestParty's model addresses both halves β€” a 14-day initial remediation cycle turning findings into source-code pull requests, then daily AI scans plus monthly expert manual audits with date-stamped reports. In the history of the company, fewer than 1% of customers have been named in accessibility lawsuits while on the platform. For the fix work criterion by criterion, see our guide to WCAG remediation in source code.

Frequently Asked Questions

How many success criteria does a WCAG audit test? Fifty-five for a Level AA target: 31 Level A plus 24 Level AA criteria in WCAG 2.2 (W3C). Each is assessed on every sampled page and recorded as passed, failed, not applicable, or not checked. AAA criteria are tested only on request.

Does a WCAG audit produce a certification? No. There is no ADA certification and no W3C certification of websites. An audit produces an evaluation report and, optionally, a conformance statement naming the standard, level, scope, date, and methodology. A vendor offering to "certify" your site is describing something that does not exist in law.

Can an automated tool perform a WCAG audit? No. Automated engines evaluate the machine-checkable subset and catch roughly 60–70% of real issues in TestParty's audit work. They cannot judge whether alt text is meaningful, whether focus order makes sense, or whether an error is announced. Both blocker-class findings above were invisible to every scanner.

How long is a WCAG audit valid? As long as the code it tested. A conformance statement applies to the sampled URLs on the date of testing, which is why reports carry dates and scope notes. For sites deploying weekly, treat a full audit as an annual anchor with monitoring between releases.

What should we ask for before signing an audit contract? The sample list, the assistive-technology and browser matrix, the standard and version, the severity model, whether a retest is included, and one redacted sample finding. If that finding carries no code-level fix specification, the deliverable is closer to a scan export.

Like everything at TestParty, this article reflects our cyborg philosophy: AI handles the heavy lifting, humans bring the expertise. The data and opinions here are based on publicly available sources as of publication. TestParty is a participant in the accessibility market β€” we believe in transparency, so we encourage you to cross-reference our claims and evaluate all options for your business.

Stay informed

Accessibility insights delivered
straight to your inbox.

Contact Us

Automate the software work for accessibility compliance, end-to-end.

Empowering businesses with seamless digital accessibility solutionsβ€”simple, inclusive, effective.

Book a Demo