What website accessibility remediation actually involves
An accessibility audit identifies barriers. Remediation is the engineering and content work needed to remove them. That distinction matters because an automated report can tell you that a colour combination fails a contrast check, but it cannot by itself decide how your design system should be changed without creating problems somewhere else.
We work from the findings in an existing audit, including reports produced by another provider, or from our own accessibility audit. Each finding is traced back to the affected template, component, page or piece of content before a change is made.
Typical work includes correcting semantic HTML, restoring keyboard operation, improving form labels and error messages, repairing heading structure, changing contrast, fixing focus behaviour and reviewing alternative text. Where the same defect comes from a shared theme or component, fixing the underlying component is usually better than patching individual pages one by one.
W3C advises that automated tools cannot determine accessibility on their own and that knowledgeable human evaluation is required. That is why remediation should end with testing, rather than simply clearing warnings from a scanner. W3C guidance on evaluating web accessibility explains the role of both tools and human assessment.
WCAG remediation for common technical failures
Many accessibility defects are caused by code that appears visually acceptable but behaves incorrectly for keyboard or assistive technology users. A menu might open with a mouse but not a keyboard. A modal may trap focus. A form may display an error in red without announcing it to a screen reader. A sticky element can cover the control that currently has keyboard focus.
WCAG 2.2 provides testable success criteria covering areas such as keyboard access, focus, contrast, labels, errors, structure and input. We use the relevant criterion from the audit to guide the fix rather than making cosmetic changes that only silence one testing tool.
For example, a missing focus indicator may need a CSS change across the site's interactive components. An incorrectly labelled field may require changes to the HTML association between the label, input, instructions and validation message. Poor ARIA can require attributes to be removed as well as added because native HTML is often preferable when it already provides the required semantics.
For larger sites, repeated defects are particularly important. Correcting a shared navigation template, form component or design token can remove the same barrier from many URLs and reduce the chance of it returning during routine editing.
How we work from an accessibility audit
Your audit becomes the working specification. We review each finding, confirm where it occurs and identify whether the cause sits in page content, a reusable component, the theme, a plugin or custom code.
- Confirm the finding. We reproduce the issue and check the affected pages, components and user journey.
- Make the correction. The change is made at the most appropriate level, with preference given to fixing the source of a repeated defect rather than individual symptoms.
- Retest the result. We repeat the relevant automated or manual checks and record the outcome.
Retesting may include keyboard-only navigation, focus order, screen reader behaviour, form validation, responsive layouts and automated WCAG checks, depending on the original finding. Complex transactional journeys often need more manual testing than a straightforward content page.
If you do not yet have a report, our free accessibility checker can provide an initial automated view, but it should not be treated as a complete accessibility assessment.
Evidence matters after accessibility fixes
A useful remediation record should show more than a list of closed tickets. For each material finding, it should be possible to identify what was wrong, what changed and what was tested afterwards. This is valuable for internal teams, future developers and organisations that need to demonstrate how accessibility problems are being addressed.
For UK public sector websites, GOV.UK guidance says accessibility problems should be identified, planned for and reflected accurately in the site's accessibility statement. It also says statements should be reviewed and updated regularly. Private organisations may have different legal obligations, but an accurate record remains useful when customers, procurement teams or regulators ask how accessibility is being managed.
After remediation, an accessibility statement should describe the website as it actually stands rather than making a blanket claim that has not been supported by testing.
Accessibility remediation pricing and ongoing monitoring
The cost of remediation depends on the findings and the way the website is built. A single shared component can sometimes resolve many reported failures, while a custom checkout, booking system or heavily modified theme may require more involved development and testing.
Where an audit already exists, the findings can be used to define the remediation work before development starts rather than leaving the scope open ended. The published EAA Compliance Package is £1,049 and includes a full WCAG 2.2 AA audit, remediation of critical and serious issues, an accessibility statement, staff briefing document, compliance evidence pack and three months of monitoring.
After the immediate work is complete, accessibility monitoring is available from £69 a month. It combines recurring scans with human review so regressions introduced by new content, theme changes or third-party components can be identified.