How the audit works

In plain terms: two weeks, one expert, one report — the kind your engineers can act on line by line and your auditor will accept as evidence. Everything below is exactly what happens, day by day. Read the parts that are yours; skim the parts that aren't.

The standard behind the method — WCAG-EM

The day-by-day below isn't an ad-hoc checklist. It's an implementation of WCAG-EM 1.0, the Website Accessibility Conformance Evaluation Methodology — the W3C's own procedure for judging whether a site conforms to WCAG. It's the methodology EU regulators and procurement teams recognise, and it's what turns "I looked at your site" into "I ran a structured conformance evaluation you can put in front of an auditor." Every audit I run maps to its five steps:

1. Define the scope — the intake questionnaire and the Day 1 scope letter fix the conformance target (WCAG 2.2 AA + EN 301 549 V3.2.1), the languages, and the breakpoints in writing before any testing starts.
2. Explore the target — Day 2's component catalog walks the site to surface every distinct page type and interactive component, so nothing structural is missed in the sample.
3. Select a representative sample — the in-scope URLs are chosen to cover each page type plus every complete process (checkout, sign-up, contact), not a random page grab. A conformance claim is only as honest as its sample, so the sampling rationale is stated, not assumed.
4. Audit the selected sample — Days 3–8: automated triage, three-platform screen-reader passes, keyboard and ARIA, forms, multimedia, contrast and reflow — each finding recorded against a specific success criterion.
5. Report the findings — Day 9's EN 301 549 success-criterion (SC) enumeration table and the Day 10 read-out. Every applicable SC gets a pass / fail / not-applicable state and the evidence behind it.

Each step is spelled out below — scope, sampling, then the day-by-day audit and report. The scope, the sampling, and the reporting shape are what make it a conformance evaluation rather than a spot-check.

Step 1 · Define the scope — Intake (async)

A 10-item written questionnaire returned a week before the kickoff. It lists:

• In-scope URLs and templates
• Languages and locale variants
• Screen widths to test (typically 320 px / 768 px / 1280 px — mobile, tablet, desktop)
• Prior reviews or audits (internal or external)
• Specific conformance claims the client wants verified
• PDFs, video, audio, or non-web documents in scope
• Regulatory deadlines (procurement, Request-for-Proposal (RFP) responses, EAA enforcement window)
• Primary user demographics (assistive-technology use, if known)
• The engineering team's tech stack and continuous-integration (CI) setup
• Anything the client already knows is broken

Returning the questionnaire turns the Day 1 kickoff into a scope confirmation rather than a scope discovery — that's the difference between a kickoff that takes 30 minutes and a kickoff that takes 90.

Steps 2 & 3 · Explore the site, then choose the sample

You can't test every URL on a real site, and you shouldn't pretend to. WCAG-EM's answer is a representative sample: a defined set of pages that stands in for the whole, chosen on stated criteria and written into the report. This is the step that separates a real conformance evaluation from "I clicked around your homepage" — and the one cheaper audits skip.

How I choose the pages that represent your site:

• One of each page type. From the component catalog (the explore step), every distinct template — home, listing, product / detail, article, form, search results, account, checkout, error / 404 — contributes at least one page. Miss a template and you miss every barrier baked into it.
• Every complete process, end to end. Any journey a user has to finish — sign-up, log-in, checkout / payment, contact, booking — is sampled as a full flow, not a single screen. Processes are where conformance failures actually block people, and where regulators look first.
• The shared furniture, once. Global navigation, cookie-consent, search, and footer appear on every page, so they're tested once, thoroughly, and counted as covering the whole site.
• Risk- and traffic-weighted extras. Your highest-traffic pages, and anything you flagged as already broken in intake, are added on top of the structural sample.

Why the number isn't arbitrary. The size of the sample follows the site, not a price list. A five-template brochure site with one contact form is a genuinely smaller evaluation than a twelve-template store with a multi-step checkout and an account area — so that's exactly what the audit is scope-priced against: your number of key page types and complete flows, agreed in writing at the kickoff. The sampling rationale and the final page list ship inside the report, so anyone who reviews it — a regulator, your lawyer, a second auditor — can see what was covered and why. A bare page count is what a cheaper competitor hands over; a documented sample is what a supervisory file needs.

Steps 4 & 5 · Audit the sample, then report — 10 working days

Day 1 — Kickoff (morning) + automated triage starts (afternoon)

Half-hour kickoff call. Scope letter signed in the call (one paragraph naming in-scope properties, languages, breakpoints, and pages explicitly excluded). The Day-10 read-out call is reserved on the calendar before any other work begins, so the engineering hand-off is committed from day one.

Afternoon: axe-core (automated accessibility testing) configured against every in-scope template. Issue triage begins.

Day 2 — Automated triage + component cataloguing

axe-core triage continued — issues clustered by success criterion, not by URL, so the SC enumeration table on Day 9 maps cleanly. Duplicate-instance issues collapsed to a single SC entry with affected URLs listed.

Component catalog produced: every interactive component on the site (modals, accordions, tabs, carousels, dropdowns, date pickers, file pickers, custom selects, autocomplete inputs). Each component becomes a unit of manual testing in Days 6–7.

Days 3–5 — Manual screen-reader passes

Three platforms, three readers, three days:

• VoiceOver + Safari on macOS — every in-scope page, reading-order pass + interactive-control pass
• VoiceOver + Safari on iOS — every in-scope page at 320 CSS px width, tap-target verification
• NVDA + Firefox on Windows — the same in-scope set
• TalkBack + Chrome on Android — for any property whose user analytics shows ≥ 10 % Android mobile traffic

Findings recorded against the EN 301 549 § 5.7 / WCAG 2.2 requirement, not against "the screen reader didn't say something" generically.

Day 6 — Forms + interactive components

The next two days name specific success criteria. If the SC codes aren't your job, the one-line version is: every form and interactive component is tested against the exact requirements that govern it.

Forms first: labeling (SC 1.3.1, 3.3.2), instructions, required-field indication, error identification (SC 3.3.1), error suggestion (SC 3.3.3), error prevention for legal / financial / data-modification flows (SC 3.3.4), input purpose / autocomplete (SC 1.3.5).

Then each catalogued component tested against the relevant success criteria: focus management, keyboard support, ARIA state changes, live-region announcements (SC 4.1.3), reduced-motion handling for animated components (SC 2.3.3).

Day 7 — Keyboard + focus + ARIA semantics

Keyboard-only navigation across every in-scope flow. Focus order (SC 2.4.3), focus traps inside every modal / dialog, focus return on dialog close, focus visibility (SC 2.4.7 + 2.4.11), tabindex audit (no values above 0), skip-link verification.

ARIA semantics review: role / state / property correctness, common misuses flagged (e.g. aria-label on non-interactive elements, redundant aria-haspopup, missing aria-expanded on disclosure widgets, role overrides that fight implicit semantics).

Day 8 — Multimedia, language, content artifacts

Criterion-level detail again — the takeaway is that video, audio, language, contrast, and the cookie-consent flow are each tested to their specific criteria.

• Video: captions (SC 1.2.2), transcripts (SC 1.2.3), audio description (SC 1.2.5), autoplay + audio control (SC 1.4.2)
• Audio: transcripts (SC 1.2.1), media controls (SC 1.4.2)
• Language: lang attribute on root (SC 3.1.1), inline language changes (SC 3.1.2)
• Contrast + zoom: 4.5:1 AA / 7:1 (AAA principle) in tested scope for every interactive control + body-text element; layout-reflow audit at 320 CSS px and 200 % zoom (SC 1.4.10); text-spacing audit (SC 1.4.12)
• Cookie consent flow: every in-scope user-visible state of the consent banner — this is the single most common audit finding on EU sites and is treated as a separate surface
• Help / support documentation: EN 301 549 clause 12 (documentation + support) — frequently omitted from audits, in scope by default here

Day 9 — EN 301 549 SC enumeration + accessibility statement

Cross-reference all findings against the EN 301 549 V3.2.1 success-criterion mapping. Produce the SC enumeration table — the document procurement asks for: every applicable SC, its pass / fail / N/A state in the tested scope, and the specific findings supporting that state.

Draft the EN 301 549 § 9.6 / Implementing Decision (EU) 2018/1523 accessibility statement, ready to publish at the client's /accessibility URL on Day 11. See the Hour Terms statement for the format.

Day 10 — Read-out (60 min) + handoff

One screen-share with engineering. Walk through findings in priority order, answer questions, mark which SCs the team plans to remediate in-house vs. refer out.

Hand off the deliverable package: SC enumeration table, prioritized remediation guidance, draft statement, axe-core CI configuration ready to drop into the client's pipeline.

The report is structured to WCAG-EM, with the tested sample and the rationale for choosing it documented — the evidence a supervisory file needs, and the thing a cheaper scan won't have written down.

What each finding includes

Every finding in the SC enumeration table carries:

• SC reference: the specific WCAG 2.2 + EN 301 549 success-criterion identifier and its level (A / AA / AAA)
• Severity: critical / serious / moderate / minor — mapped against the client's existing P0–P3 / S1–S4 scheme during the kickoff
• User impact: which user groups are affected (screen-reader users, keyboard-only users, low-vision users, users with cognitive disabilities, users with motor disabilities)
• Effort estimate: developer-hours, banded (≤ 1 h / 1–4 h / 4–8 h / 8+ h)
• Affected URLs or components: the specific surfaces where the finding applies
• Minimal reproducible example: enough HTML / CSS / JS to reproduce in isolation
• Recommended fix: paste-ready code, keyed to the framework named in the intake (React + ARIA, Vue + ARIA, plain HTML, etc.)

This is the deliverable shape most often missing from cheaper audits — they hand over a PDF; this audit hands over an issue tracker import.

What's not in the methodology

Stating the negative is part of the contract. The following are out of scope of the 2-week audit — some are separate engagements, some I refer out:

• Penetration testing / security audit — out of scope, different specialty
• Writing remediation code changes — that's the EAA Remediation Sprint, a separate engagement
• Re-audit after remediation — separate engagement, scheduled at the read-out call
• Native mobile apps — see the scope page
• AI-powered interfaces — see the scope page

Scope extensions (priced at kickoff)

These are add-ons you can bundle at kickoff, each priced per unit below:

• PDFs: €1,200 per cluster of up to 10 documents (PDF/UA tag review, semantic structure, alt text, reading order)
• Multi-language: each additional language audited at €600 per locale (assumes content parity; new components per locale are extra)
• Multi-region / multi-brand: €1,200 / day, scoped at the kickoff
• Team training: half-day or full-day accessibility workshops at €125 / hour

How the price works out

From €3,500 covers the 10 working days described above for a single in-scope property, single language, single brand, web-platform only. Larger sites scope up within the €3,500–€7,500 range; the price reflects page count and flow complexity. The intake questionnaire and Day 0 kickoff are not separately billed.

€1,200 / day for multi-domain, multi-region, or multi-language scope. Day count scoped at the kickoff call. Everything in this number is what's on this page.

Two weeks. One auditor. One report. Compare to an agency audit: a typical mid-market quote is €15,000–30,000 for similar scope, with most of that going to project managers, account directors, and the agency's overhead. I don't charge for the org chart.

Last reviewed

Methodology last reviewed 2026-07-27. If a step in the day-by-day above changes, the date here updates and the previous version stays in the git history.