Our website accessibility compliance service audits your live site against WCAG 2.1 AA, repairs the agreed defects in a bounded remediation sprint, retests every fix, and hands you a dated conformance report an internal reviewer can actually inspect. Fixed scope, three inspectable deliverables, no open-ended billing.
Need accessibility evidence fast? Request a fixed-scope accessibility audit — tell us your site and priority journeys, and we'll scope the audit within one business day.
What Does This Accessibility Compliance Service Actually Do?
It turns undocumented accessibility defects into an agreed repair list plus a retained verification record. You commission it when your team suspects the site has barriers — a keyboard user trapped in a menu, a screen reader hearing nothing useful from an icon button, an error message disconnected from its field — but nobody can say which templates fail, how serious each failure is, or whether patching is even sensible.
As Tim Berners-Lee put it: "The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect." The business case is just as blunt: the WebAIM Million 2025 study found 94.8% of the top one million home pages had detectable WCAG 2 failures, averaging 51.4 errors per page — and US digital-accessibility lawsuits topped 5,000 filings in 2025. Most organisations are exposed; few can prove otherwise. This service produces the proof.
The legal question stays separate. Whether the European Accessibility Act — applicable to private-sector digital services since 28 June 2025 — or another rule covers your organisation is for qualified counsel to decide, not a technical audit. Read our European Accessibility Act website readiness guide for the regulatory picture, then have counsel confirm your obligation and technical target. Our EAA compliance overview covers what the directive means for websites specifically.
Which Engagement Fits: Audit, Remediation Sprint, or Rebuild?
| Engagement | You receive | Choose it when | Boundary |
|---|---|---|---|
| Audit only | Prioritised findings register (element, criterion, required repair) | You need independent scope, or your own developers will fix | No production code changes |
| Audit + remediation sprint | Findings register, accepted repairs, change log, retest record, conformance report | The codebase is maintainable and defects are bounded | Only agreed templates, components, journeys |
| Accessible rebuild | Replacement templates/app built to approved accessibility acceptance criteria | The architecture regenerates inaccessible output | A new build, not a bigger patch |
The audit is the decision gate. It stops a supplier promising a small fix before anyone has checked whether the same fault is baked into every template — and it stops a repairable site being rebuilt just because a rebuild is easier to sell. Before deciding who does the work, compare offshore vs. agency vs. boutique web development models for accountability differences. If the verdict lands on rebuild, the findings become acceptance criteria for the new build; nothing is discarded. A rebuild of this kind is scoped like any serious core web development engagement, with accessibility criteria written into the contract.
What Are the Three Deliverables?
Each stage ends with an output you can inspect — that's what makes fixed scope possible.
1. WCAG 2.1 AA audit. We agree the scope up front: which templates and journeys get tested (navigation, search, account, checkout, booking, contact), and which browser plus assistive-technology combinations the test plan uses. Automated checks catch machine-detectable failures; manual interaction testing — keyboard-only runs and screen-reader passes — catches what tools miss. Every finding is recorded with six fields: identifier, severity, affected element, test criterion, observed failure, and required repair. Scope is agreed before a single line of code changes.
2. Remediation sprint. We apply the accepted fixes to your current codebase, with each change referencing its finding identifier so the link between problem and repair survives in the commit history. Anything outside the agreed templates, third-party systems we can't edit, or new features stays out unless added by written change. Fixed price means the statement of work names the tested surface, accepted findings, dependencies, exclusions, and acceptance checks before implementation — not that every future defect is silently included. The sprint follows the same scoping discipline as our fixed-price web design packages: named surface, named findings, named acceptance checks. See our pricing for how the fixed-scope model works.
3. Accessibility conformance report. The handover artefact: target, tested scope, methods, test date, resolved findings, retest outcomes, explicit exclusions, and any accepted limitation that remains. Both the report and the change log are yours at handover — you own the evidence.
What Can the Conformance Report Claim — and What Can't It?
Stated plainly, because this boundary matters:
It can state that the named scope was tested against the stated target on a recorded date; which methods and assistive-technology combinations were used; which findings were repaired, with the retest outcome of each; and which surfaces were excluded — third-party payment frames, embedded booking widgets, archived documents, pages outside the agreed template inventory.
It cannot state that your whole organisation meets every legal obligation; which law applies or whether an exemption exists; that untested pages conform; or that a regulator or procurement reviewer is satisfied — those conclusions need legal and contractual context this technical service doesn't supply.
Exclusions are named directly, not buried in general terms, so you can assign each one to the right owner — and independent client reviews show how seriously we take that transparency. For the European buyer perspective — how a procurement reviewer actually reads submitted evidence — see our companion guide on accessibility evidence for European buyer sign-off.
Remediation or Full Rebuild: How Do You Decide?
Repair when the current code can produce correct headings, landmarks, labels, focus order, states, and error handling after bounded changes — e.g., a shared navigation component needs corrected naming and focus behaviour, or form fields can take persistent labels without replacing the form platform.
Rebuild when inaccessible output is structural: the component library strips semantic controls, the CMS regenerates defective markup after every editorial publish, or one journey needs fragile overrides across dozens of unrelated templates. In that case isolated patches will rot within months.
A worked example of the evidence chain: finding A-01 flags an icon-only header menu toggle with no programmatic name (WCAG 2.1 criterion 4.1.2). The accepted repair specifies a stable accessible name plus exposed expanded/collapsed state. The implementation record maps the code change to A-01, the same interaction is retested with the agreed method, and the conformance report records the dated result — without extending the claim to untested pages. That's more useful than any dashboard score: you can inspect what changed, and a future maintainer inherits the context. When a rebuild is the verdict, plan it as a website redesign with an SEO migration checklist so accessibility gains don't cost you rankings — scoped through our core web development services.
How Is This Different From a Technical SEO Audit?
They answer different questions with different evidence:
| Accessibility engagement | Technical SEO engagement | |
|---|---|---|
| Primary user | People completing tasks, incl. assistive-tech users | Search crawlers and organic visitors |
| Core evidence | Findings by element/criterion, manual test log, repairs, retests | Crawl records, indexation findings, rendering checks, performance diagnostics |
| Typical decision | Repair barrier, replace component, or rebuild | Fix discovery, rendering, architecture, performance |
| Handover | Conformance report for the named scope | Findings plus implementation priorities |
Overlap is limited to semantic HTML and performance. A clean crawl never proves a person can operate your menu, and a passing keyboard test says nothing about your canonical tags. If you need both, run our technical SEO audit alongside — our Core Web Vitals and crawl-budget playbook shows what the performance side covers — but don't confuse one for the other.
What Do You Need Before Requesting a Fixed Scope?
You're ready for a bounded proposal once you can name: the website, who controls code/hosting/CMS/deployment, the template inventory in scope, priority journeys (enquiry, booking, purchase, account), the technical target (default WCAG 2.1 AA, or counsel's alternative), third-party boundaries we can't edit, any planned migration (don't remediate code slated for retirement), and the evidence owner who receives the report. Submit the readiness inputs via our project form and we'll return a fixed scope. Missing inputs don't kill the engagement — they just mean an audit-only or discovery stage comes first. And if your site collects personal data, note that accessibility evidence isn't privacy compliance; our GCC data protection guide covers that separately.
Frequently Asked Questions
Is WCAG 2.1 AA the standard used for the audit?
Yes — WCAG 2.1 AA is the default technical target. If your counsel, procurement team, or a retained requirement specifies another version or level, the statement of work names that target before testing begins. The target is always explicit, never assumed.
Does the conformance report make my website legally compliant?
No. It documents the tested technical scope, methods, findings, repairs, and retest outcomes on a recorded date. Only qualified counsel can decide which law applies to your organisation and whether the tested scope satisfies that obligation. Treat the report as evidence, not a legal ruling.
Do you retest after remediation?
Yes. Every accepted repair is retested against the finding and method recorded in the audit, and the handover report states the resulting status per item. Untested pages are never claimed as conforming — the report's boundary is explicit.
Can we commission just the audit, without remediation?
Yes. An audit-only engagement suits teams whose own developers (or another supplier) will implement the repairs. The findings register is written specifically enough to implement and verify each fix independently — identifier, criterion, observed failure, required repair. Contact us with your site URL and we'll scope the audit alone.
What happens if the audit shows the site should be rebuilt?
The audit separates repairable findings from architecture-level failures and records the structural constraint. Fixes stop at the agreed boundary, and the retained findings carry over as acceptance criteria for the replacement build. You don't pay for patches that the next deploy would undo.
Is this the same as an EAA legal assessment?
No. The service implements and tests a technical target your counsel approves for the website, but it doesn't decide whether the European Accessibility Act applies to your business or service. For the regulatory side, start with our EAA website readiness guide.
The Bottom Line
Accessibility work is only worth buying when you can inspect what was found, what was fixed, and what was proven. That's the whole design of this service: a six-field findings register, a bounded remediation sprint, and a dated conformance report that says exactly what it covers — and what it doesn't.
Start with the audit. Contact our team with your website and priority journeys, and we'll return a fixed-scope proposal — or scope your project instantly with our quote calculator.
Written by the WebStackRank web development team — practitioners who audit, remediate, and support production websites across the GCC, Europe, and the USA. Last reviewed: October 2026.
