Skip to main content
← All resourcesAccessibility

Website accessibility audit vs. remediation: what are you buying?

An accessibility audit identifies and explains barriers. Remediation changes the website to address them. Verification checks those changes. Specify all three responsibilities when planning the work, because an issue report by itself does not fix a website.

By Awesome Cause · About our founder · · Updated · 2 min read

What an audit should deliver

Define the scope before testing begins: pages, templates, documents, third-party tools and important tasks such as applying, donating or signing in. Specify the accessibility standard and conformance level being evaluated.

For each finding, ask for the affected location, the barrier, steps to reproduce it, the relevant criterion and guidance for correction. Agree on how recurring issues will be grouped. A shared navigation problem may appear on hundreds of pages while requiring a change in one component.

Why automated scans are only part of the work

Automated checks can help locate some issues, but human evaluation is necessary to assess conformance. W3C explicitly notes that no tool alone can determine whether a site meets accessibility standards. W3C evaluation guidance

Ask how the audit will cover keyboard operation, focus behavior, form errors, meaningful text alternatives and complete user journeys. Specify which assistive technologies and browsers will be used. Testing individual pages can miss a barrier that appears only halfway through a process.

What remediation includes

Remediation may involve templates, components, content, documents and connected services. It can require coordination between a developer, content editor and external vendor. Ask who owns each kind of repair and how the work will be prioritized.

  • Address barriers in essential journeys and shared components.
  • Group repeated problems so changes are consistent.
  • Record work that depends on a third-party vendor.
  • Document content changes and train editors where needed.
  • Recheck fixes and watch for new issues caused by the changes.

The estimate should distinguish work on your own site from work that requires vendor access or a separate document project.

Agree on verification and acceptance

A completed ticket is not the same as a verified repair. Reproduce the original issue after the change, retest the affected journey and record the outcome. Decide who reviews fixes and what evidence you receive.

Be precise about sampling. An evaluation of selected pages should not be presented as a test of every page and file. Ask how remaining issues, exceptions and dependencies will be documented so you know what is still unresolved.

Plan for the next content update

Accessibility work continues as staff publish pages, upload files and add new tools. Assign responsibility for content practices, periodic checks and responding to reports. W3C provides a framework for planning and managing that ongoing work. W3C planning resources

If you are buying an audit, ask who can implement the findings. If you are buying repairs, ask who checks them. If you are buying a redesign, put testing and correction milestones into the project from the start.

Prepared by Awesome Cause with AI assistance. These guides provide planning advice; project scope and estimates are agreed individually.

Let's talk about your project!

Send a short note about what needs to change. Daniel will reply personally, talk through scope and budget, and arrange a conversation if it would help.

Tell us about your project

Prefer email? hello@awesomecause.com

Tell us about your project

Start with a short note.

Tell us a little about the project. Daniel will reply personally within one business day and arrange a time to talk if it would help.

What do you need?
Two or three sentences is plenty.

Prefer email? hello@awesomecause.com. No newsletters, no spam, ever.