Methodology

Before the audit — Intake (async)

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

• In-scope URLs and templates
• Languages and locale variants
• Breakpoints to test (typically 320 px / 768 px / 1280 px)
• 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, RFP, EAA enforcement window)
• Primary user demographics (assistive-tech usage if known)
• The engineering team's framework + CI tooling
• 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.

Inside the audit — 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 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 catalogue 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

Forms first: labelling (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 SCs: 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

• 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-in-tested-scope for every interactive control + body-text element; layout-reflow audit at 320 CSS px and 200 % zoom (SC 1.4.10); spacing-override 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, prioritised remediation guidance, draft statement, axe-core CI configuration ready to drop into the client's pipeline.

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 and are documented in What I don't sell:

• User testing with disabled users — different engagement, referred to a specialist
• Penetration testing / security audit — out of scope, different specialty
• Writing remediation PRs — that's the remediation sprint, which I don't sell
• Re-audit after remediation — separate engagement, scheduled at the read-out call
• Multi-day team training — referred to a Dutch a11y-training specialist. The Day-10 read-out (one hour, screen-share with engineering, walking through findings) is included in every audit
• Native mobile — referred (see scope page)
• AI / ML-mediated UX — referred (see scope page)

Scope extensions (priced at kickoff)

These are in scope at the audit's day-rate if you add them at the kickoff:

• 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: at €1,200 / day, scoped at the kickoff

How the price works out

€2,400 fixed covers the 10 working days described above for a single in-scope property, single language, single brand, web-platform only. 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-05-18. If a step in the day-by-day above changes, the date here updates and the previous version stays in the git history.