Website Accessibility Compliance Service: Audit, Remediation, Evidence
Key takeaways
- This is a fixed-scope engagement with three inspectable deliverables: an accessibility audit, a remediation sprint, and a dated conformance report.
- Each audit finding records six fields (identifier, severity, affected element, test criterion, observed failure, required repair), so scope is agreed before any code changes.
- Commission remediation when defects can be fixed inside the current templates and components; commission a rebuild when the architecture keeps regenerating inaccessible structure.
- The conformance report states the tested scope, method, date, repairs, retest outcomes, and exclusions. It does not decide whether a law applies to your organisation.
- To start, name your website, code access, technical target, priority journeys, and evidence owner; the audit then bounds the remediation before a fixed price is set.
A website accessibility compliance service audits an existing site against an agreed technical target, repairs the accepted defects, retests the affected journeys, and hands over a dated record of the work. WebStackRank delivers this as a fixed-scope engagement, so your commercial decision is concrete: commission an audit alone, an audit plus a remediation sprint, or a rebuild when the current foundation cannot be repaired economically.
WebStackRank is a Dubai-based digital agency that designs, builds, and remediates websites for business decision-makers across the GCC and Europe. This service is for organisations with a live website that need a bounded technical engagement and evidence an internal reviewer can inspect, not an open-ended stream of accessibility work.
Information gain: this page gives you the service boundary, three named deliverables, an illustrative audit-finding register, a worked repair-to-retest chain, and the exact limits of the resulting conformance report. Our separate guide to accessibility evidence for European buyer sign-off instead explains how a buyer reviews submitted evidence.
What does this accessibility compliance service fix?
It converts undocumented accessibility defects into an agreed repair scope and a retained verification record. Commission it when your team knows the site needs technical attention but cannot yet say which templates fail, how serious the failures are, or whether patching the current code is responsible. A visual inspection will not tell you that: a page can look complete while a keyboard user cannot reach a menu, a screen reader gets no useful name for a control, or an error message is disconnected from the field that caused it.
The legal question stays separate. Whether the European Accessibility Act or another rule applies to a particular organisation is not decided by this technical service. Read the overview of what the European Accessibility Act can mean for a website, then have qualified counsel confirm the obligation and the technical target.
Which engagement should you commission: audit, remediation sprint, or rebuild?
Commission an audit when you need a defect register but another team will implement repairs. Commission an audit plus remediation when the codebase is maintainable and the identified failures can be corrected inside it. Commission a rebuild when the templates, component system, or CMS keep generating inaccessible output.
| Engagement | Delivered output | Choose it when | Boundary |
|---|---|---|---|
| Audit only | Prioritised findings register with affected elements, criteria, and repairs | You need an independent technical scope, or your own developers will fix it | No production code is changed |
| Audit and remediation sprint | Findings register, accepted repairs, change log, retest record, and conformance report | The site is structurally sound and the defects are bounded | Only agreed templates, components, and journeys are included |
| Accessible rebuild | Replacement templates or application built around approved accessibility acceptance criteria | Broken structure is repeated by the architecture or publishing system | A new build, not a larger patch sprint |
The audit is the decision gate. It stops a supplier promising a small remediation before anyone has checked whether the same fault is embedded across every template, and it stops a repairable site being replaced only because a rebuild is easier to sell.
What you commission: the three deliverables
Each stage ends with an output you can inspect, which is what makes the engagement suitable for a fixed scope.
1. WCAG 2.1 AA audit
The default technical target is WCAG 2.1 AA. The agreed scope names the templates and journeys to be tested, such as navigation, search, account access, checkout, booking, or contact, and records the browser and assistive-technology combinations in the test plan.
Automated checks catch certain machine-detectable failures, but the scope also includes manual interaction testing. According to WebStackRank's Website Development Process SOP, published 18 May 2026, our standard QA accessibility pass combines axe-core with a manual screen-reader test. The standalone service turns that documented method into a scoped findings register rather than an informal final check.
2. Remediation sprint
The remediation sprint applies the accepted fixes to the current codebase. Each code change references a finding identifier, preserving the link between the observed problem and its repair. Work outside the agreed templates, third-party systems that cannot be edited, and new features stay out of scope unless added by a written change.
The sprint becomes fixed-scope only after the audit has bounded the work. Fixed price does not mean every possible future defect is silently included; it means the statement of work names the tested surface, accepted findings, dependencies, exclusions, and acceptance checks before implementation starts. Our published pricing structure explains the wider fixed-scope model without asserting a price for this service.
3. Accessibility conformance report
The handover deliverable is a written accessibility conformance report plus the change log. It records the target, tested scope, methods, test date, resolved findings, retest outcomes, and explicit exclusions, and it names any accepted limitation that remains. Both artefacts belong to you at handover under our ownership model.
Illustrative audit-finding format: six fields per defect
This page-specific example shows the format of the register. It is illustrative and contains no client data, test result, or claim about a live website; the hypothetical menu control only demonstrates how the evidence chain is structured.
| ID | Severity | Affected element | Test criterion | Observed failure | Required repair |
|---|---|---|---|---|---|
| A-01 | Critical | Header navigation toggle | WCAG 2.1 success criterion 4.1.2 | The icon-only button has no programmatic name, and its expanded state is not exposed | Provide a stable accessible name and expose the current expanded or collapsed state |
| A-02 | Serious | Contact enquiry fields | WCAG 2.1 success criterion 3.3.2 | Purpose is shown only through placeholder text, which disappears after input begins | Add persistent visible labels and programmatically associate each label with its field |
| A-03 | Moderate | Inline validation message | Agreed error-identification test | The message appears visually but is not connected to the field or announced after submission | Associate the message with the field and confirm the changed error state is announced |
Severity controls sequencing, not rhetoric. A finding that blocks an agreed journey is addressed before one that adds friction without preventing completion. The severity model and acceptance rule are written into the scope, not inferred after delivery.
Worked repair-to-retest chain
Finding A-01 above shows the complete evidence path, from observation to a dated retest result.
- Finding A-01 identifies one control, one observed failure, and one criterion.
- The accepted repair specifies the required name and state behaviour.
- The implementation record maps the code change back to A-01.
- The same interaction is retested using the agreed method.
- The conformance report records the result without extending it to untested pages.
This is more useful than a dashboard score because you can inspect what changed, and a future maintainer keeps enough context to investigate if the component is later replaced.
What can the conformance report claim, and what can it not?
The report is a technical record, not a legal ruling. Stated plainly, here is the boundary.
The report 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 for each;
- which surfaces were excluded, such as third-party payment interfaces, embedded booking systems, archived documents, or pages outside the agreed template inventory.
The report cannot state:
- that an entire organisation satisfies every legal obligation;
- which law applies, or whether an exemption exists;
- that untested pages conform;
- that a regulator or procurement contract is satisfied, since those conclusions need the relevant legal and contractual context.
Exclusions are named directly rather than buried in general terms, so you can decide whether another supplier or internal owner must address them.
Remediation or a full accessible rebuild?
Remediation fits when the current code can produce correct headings, landmarks, labels, focus order, states, and error handling after bounded changes. A rebuild fits when inaccessible output is a structural property of the templates or publishing system and would return after isolated patches.
- Repair when a shared navigation component needs corrected naming, state, or focus behaviour.
- Repair when form fields can receive persistent labels and connected validation without replacing the form platform.
- Rebuild when the component library repeatedly removes semantic controls or blocks required keyboard behaviour.
- Rebuild when the CMS regenerates defective markup after every editorial update, or one journey needs fragile overrides across many unrelated templates.
If the audit reaches the rebuild side of that boundary, the next step is an architecture-level assessment, and the original findings should become acceptance criteria for the new build rather than being discarded.
How does this differ from a technical SEO audit?
Accessibility remediation tests whether people, including keyboard and assistive-technology users, can perceive and operate the agreed journeys. A technical SEO audit examines whether search systems can crawl, render, understand, and index the site, and may evaluate performance. Neither replaces the other.
| Area | Accessibility engagement | Technical SEO engagement |
|---|---|---|
| Primary user | People completing website tasks, including assistive-technology users | Search crawlers and people arriving through organic search |
| Core evidence | Findings by element and criterion, manual test log, repairs, and retests | Crawl records, indexation findings, rendering checks, and performance diagnostics |
| Typical decision | Repair a barrier, replace a component, or rebuild inaccessible structure | Correct discovery, rendering, internal architecture, or performance problems |
| Handover | Conformance report for the named accessibility scope | Technical SEO findings and implementation priorities |
Overlap is limited to semantic HTML and performance. A passing crawl does not prove a person can operate a menu, and a successful keyboard test says nothing about canonical tags or indexation.
Before you request a fixed scope
You are ready for a bounded proposal once the website, access, technical target, priority journeys, and evidence owner can be named. Missing inputs do not make the service impossible, but they may require a discovery or audit-only stage before remediation can be priced responsibly.
- Code access: who controls the repository, hosting, CMS, and deployment.
- Template inventory: the layouts and components that generate the pages in scope.
- Journey priority: the tasks that must be tested, such as enquiry, registration, booking, purchase, or account access.
- Technical target: WCAG 2.1 AA or the alternative approved by your counsel or procurement reviewer.
- Third-party boundary: embedded services your development supplier cannot edit directly.
- Rebuild timing: any planned migration, so defects are not repaired in code scheduled for retirement.
- Evidence owner: the person who will receive, retain, and review the report.
If your site also collects personal information, accessibility evidence is not privacy compliance; the separate guide to data protection and privacy obligations in GCC markets covers that concern.
How to commission the service
Send the readiness inputs above and we scope an audit against WCAG 2.1 AA for the named journeys. The audit output decides whether a bounded remediation sprint or an architecture-level rebuild is the right spend, and either path ends with the conformance report in your hands. Start by telling us your website and priority journeys.
Frequently asked questions
Is WCAG 2.1 AA the standard used for the audit?
Yes, WCAG 2.1 AA is the default technical target for this service. If counsel, procurement, or a retained requirement specifies another version or level, the statement of work must name that target before testing begins.
Does the conformance report make a website legally compliant?
No. It documents the tested technical scope, method, findings, repairs, and retest outcomes. Qualified counsel must decide which law applies and whether the selected scope satisfies the organisation's obligation.
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 for that item.
Can we commission the audit without the remediation sprint?
Yes. An audit-only engagement suits an internal team or another supplier performing the repairs. The delivered register still makes each finding specific enough to implement and verify.
What happens when the current website should be rebuilt?
The audit records the structural constraint and separates repairable findings from architecture-level failures. Remediation stops at the agreed boundary, and the retained findings become acceptance criteria for the replacement build.
Is this the same as an EAA legal assessment?
No. The service can implement and test a technical target approved for the website, but it does not decide whether the European Accessibility Act applies to a particular business or service.
