Web Development
Accessibility Remediation (WCAG)
Automated tools find about a third of accessibility issues. The other two-thirds need a person, and they are usually the ones that stop someone completing a task.
Accessibility remediation brings an existing site up to WCAG 2.2 AA. The Nexclick audits against the standard, fixes in order of user impact, and tests with real screen readers rather than an automated scan — which catches roughly a third of the barriers that actually matter.
Is this you?
What usually prompts the call
- A customer has told you they cannot use your site, or you have received a complaint.
- A public sector or enterprise client requires an accessibility statement you cannot honestly write.
- You ran an automated scan, fixed what it found, and are unsure what that leaves.
- You are procuring or tendering and accessibility is a scored requirement.
What we do
The actual deliverables
Things that appear on an invoice, not adjectives.
- Automated scan as a starting point only
- Fast and useful for finding contrast failures and missing labels at scale. It catches roughly a third of real barriers, and treating it as the audit is the common mistake.
- Manual testing against the standard
- Each applicable WCAG 2.2 AA criterion checked by hand across template types. This is where the barriers that actually block people are found.
- Keyboard-only walkthrough
- Every journey completed without a mouse. Focus traps, invisible focus and unreachable controls are common and are absolute blockers for the people affected.
- Screen reader testing
- NVDA and VoiceOver at minimum. A page that passes an automated scan can still be unusable when read aloud, and only listening to it reveals that.
- Prioritised remediation plan
- Ordered by user impact rather than by scan severity. A missing form label matters more than a decorative image without alt text, and tools score them the other way round.
- Implementation or specification
- Fixes applied by us, or specified precisely enough for your developers to implement in a sprint.
- An honest accessibility statement
- Stating what conforms, what does not, and what is planned. A statement claiming full conformance when it is untrue is worse than none.
Comparison
What automated scans catch, and what they miss
Automated testing finds roughly a third of accessibility barriers. This is the split, so you know what a clean scan does and does not tell you about your site.
| Barrier | Found by automation? | Real-world impact |
|---|---|---|
| Insufficient colour contrast | Yes | High — affects many users |
| Missing image alt attribute | Yes | Depends — decorative images need empty alt |
| Missing form label | Yes | Severe — form may be uncompletable |
| Missing page language attribute | Yes | Moderate — affects pronunciation |
| Alt text that describes nothing useful | No | High — "image1.jpg" passes automation |
| Focus order that jumps around the page | No | Severe — journey becomes unusable |
| Focus trap in a modal | No | Severe — user cannot escape |
| Invisible focus indicator | Partly | Severe for keyboard users |
| Headings used for styling rather than structure | No | High — navigation by heading breaks |
| Meaning conveyed by colour alone | No | High — affects colour-blind users |
| Error messages not announced to screen readers | No | Severe — user cannot tell what went wrong |
| Custom component with no keyboard support | No | Absolute blocker |
| Video with no captions | Partly | Absolute blocker for deaf users |
| Content that changes without announcement | No | High — screen reader users miss updates |
How it works
Step by step, with timeframes
Timeframes are typical rather than guaranteed, and they assume we get account access and approvals when we ask.
- 01Week 1–3
Audit
Automated scan, manual criterion testing, keyboard walkthrough and screen reader testing across representative templates.
- 02Week 3
Prioritise
Findings ordered by user impact against effort, with each mapped to the specific WCAG criterion it fails.
- 03Week 3–8
Remediate
Fixes implemented by us or by your team against our specification, with blockers addressed first.
- 04Week 8–10
Retest and document
Verification pass, then an accessibility statement written to reflect what is genuinely true.
What you get
Reporting and ownership
- An audit mapping every finding to the specific WCAG criterion it fails, usable as evidence.
- A remediation plan ordered by user impact, not by automated severity score.
- Developer-ready specifications for anything we are not implementing ourselves.
- Retest evidence after remediation, so conformance claims can be substantiated.
- An accessibility statement written to be true, including what still does not conform.
Tools and platforms
- axe DevTools & WAVE
- NVDA (Windows)
- VoiceOver (macOS / iOS)
- Keyboard-only testing
- Colour contrast analysers
- WCAG 2.2 AA criterion checklist
Timeline
How long this actually takes
Audit takes two to three weeks. Remediation runs four to eight depending on how much is structural — contrast and labelling are quick, a custom component with no keyboard support is a rebuild. Two things worth saying plainly. Accessibility overlays and widgets that promise instant compliance do not work; they are widely criticised by disabled users and have featured in US litigation. And full WCAG conformance is a moving target on any site that keeps changing, which is why the statement should describe a position and a plan rather than a permanent claim.
Pricing model
Fixed-price project
Fixed price for the audit. Remediation is quoted once the findings are known, because the work varies enormously between a contrast fix and rebuilding a component.
Questions
Accessibility Remediation (WCAG) questions
Is our business legally required to be accessible?
Under the Equality Act 2010, service providers must make reasonable adjustments, and that includes digital services. Public sector bodies have specific regulations requiring WCAG 2.2 AA. For private businesses the obligation is less prescriptive and it does exist. Specific legal advice is a question for a solicitor rather than for us.
Will an accessibility overlay solve this?
No. Overlay widgets promising instant compliance are widely criticised by disabled users, frequently interfere with the assistive technology people already use, and have featured in litigation in the US. They treat the symptom in a way that sometimes makes the underlying site harder to use.
How much of this can automated testing find?
Roughly a third of real barriers, and it is the easier third — contrast, missing labels, absent alt attributes. The severe issues are almost all in the other two-thirds: focus order, keyboard traps, unannounced errors, custom components with no keyboard support.
Do we need to fix everything at once?
No, and prioritising is part of the deliverable. Fix the absolute blockers first — things that make a task impossible — then work down by impact. A published statement describing genuine progress against a plan is a defensible position; a false claim of full conformance is not.
Does accessibility work help SEO?
Somewhat, and it is a side benefit rather than a reason. Semantic structure, meaningful alt text and proper headings help both. The overlap is real and partial — most accessibility work has no ranking effect at all, and doing it for SEO reasons will mean doing the wrong parts.
How do we stay accessible after remediation?
Automated checks in your deployment pipeline to catch regressions, plus accessibility built into how new components are designed rather than audited afterwards. Any site that keeps changing will drift, so the practical goal is a process rather than a finished state.
Last reviewed 28 July 2026.
Tell us what you are trying to fix
A 20-minute call, no pitch deck. The Nexclick will tell you what we would do, roughly what it costs, and whether we are the right people for it.