What to Do After an Accessibility Audit

An accessibility audit report tells you where a website fails, but it does not fix anything on its own. A common outcome is a long list of failures shared with whoever built the website, followed by a burst of easy fixes and then very little else. The audit only pays off when its findings become planned work with owners, priorities and a retest at the end. That planned work is what accessibility remediation for public sector and B2B websites is meant to deliver, whatever the size of the report.

The sections below follow the order the work usually happens, from reading the findings to keeping the website accessible once the fixes are live. What gets tested in the first place is covered in our guide to what a WCAG audit tests, so the focus here is on everything that follows the report.

Group the Findings by Cause Before Assigning Work

The first job after an audit is to group the findings by cause rather than working through them in the order they appear. Audit reports usually list every instance of a failure, so the same missing form label or low contrast button can show up many times across different pages.

Grouping turns a long list into a much shorter set of underlying problems. A menu that traps keyboard focus on every page is one fix in the header template rather than one fix per page. An unlabelled search field in the header works the same way.

The W3C’s evaluation methodology describes audits that test a representative sample of web pages rather than every page on the website. Fixing the findings across the whole website therefore depends on tracing each one back to the template, component or content type that produced it. Sorting each finding into one of the groups below makes the owner of each fix clear from the start.

• Shared templates and components, such as the header, footer, navigation and form patterns
• Custom features or page layouts that appear in one place only
• Content added by editors, such as images, link text, headings and tables
• Documents and media, such as PDFs, videos and audio
• Third party tools embedded in the website, such as booking or chat tools

Each group has a different owner and a different route to a fix. Developers own the templates and custom features. Editors own the content, documents usually need input from developers and editors together and third party tools depend on whoever supplies them.

Prioritise Issues by User Impact and WCAG Level

Prioritise the issues that stop people completing a task first, then use the WCAG level and the number of affected pages to order the rest. The W3C’s explanation of understanding WCAG conformance notes that WCAG 2 does not suggest any particular level of priority or severity for its success criteria. It explains that how severe a failure is depends on how often it occurs and the type of content or functionality that is failing.

Level still matters when two failures affect similar journeys. The WordPress accessibility coding standards describe Level A criteria as barriers on a very wide scale that prevent many people from accessing a website. Level AA criteria may affect smaller groups of people but are still common needs with broad reach.

Putting impact and level together gives a simple set of tiers. A Level A failure on a contact form will usually outrank a Level AA failure on an old news page, although a Level AA failure on the most visited page of the website can move up the list.

Ranking by impact also gives the team a clear answer when someone asks why a particular issue has not been fixed yet. Priority Pixels ranks issues in its audits by impact and legal risk so it is clear what needs fixing first.

Decide What Cannot Be Fixed Straight Away

Some findings cannot be fixed straight away and each of those needs a recorded decision rather than silence. An unexplained gap looks the same as neglect to anyone checking the website, including a regulator or a procurement team.

The usual reasons are a third party tool the organisation does not control, a platform limitation that needs a larger rebuild or a cost that is out of proportion to the benefit. GOV.UK guidance on accessibility requirements for public sector bodies calls the last of these a disproportionate burden. A public body that wants to make that claim is legally required to carry out an assessment first.

That assessment weighs the burden on the organisation against the benefit to disabled users. The same guidance says lack of time or knowledge cannot be counted. Neither can the argument that the work was never given priority.

Exempt content needs the same openness. PDFs published before September 2018 that people do not need to use a service, live audio and video and third party content the organisation did not pay for or develop are among the exemptions, but each one still has to be explained in the accessibility statement. The accessibility requirements for public sector websites set out the public sector duties in more depth.

Build a Remediation Plan With Owners and Dates

A remediation plan turns the prioritised list into scheduled work, with a named owner and a target date for every group of issues. GOV.UK guidance on how to make your website accessible and publish an accessibility statement recommends talking to suppliers, developers and content editors about how long each fix will take and how difficult it will be.

The same guidance suggests building a roadmap once the priorities are agreed. It also recommends planning improvements around natural opportunities, such as appointing a new supplier or changing a section of the website.

Dates matter beyond project management, because the accessibility statement should say when known problems are expected to be fixed. A plan without dates leaves the statement vague and gives anyone who reports a problem no idea when to expect a change.

Where a supplier built or hosts the website, agree the plan with them in writing. GOV.UK states that a public body is legally responsible for its website meeting the accessibility requirements even when the website has been outsourced to a supplier.

Fix Problems at Template Level First

Fixing a problem in the template or component that produces it clears every page that uses it at once, so template fixes should come before page by page work. On a WordPress website that usually means changes to the theme’s header, footer, navigation and form handling, along with the blocks editors use to build pages.

Custom components such as menus, accordions, tabs and modal dialogs are where many audit failures start. The W3C’s ARIA Authoring Practices Guide warns that no ARIA is better than bad ARIA, because an ARIA role is a promise that the matching keyboard behaviour has also been built. Native HTML elements avoid most of that risk, since a real button brings keyboard support with it that a styled div does not.

Overlay widgets deserve a specific mention because they are often offered as a quick answer to an audit report. They sit on top of the page rather than fixing the templates the audit tested, which is why the risks of accessibility overlays are worth understanding before anyone suggests one.

Forms are the other area where template work pays back quickly, since one form pattern is often reused across contact, booking and download pages. Our guide to designing accessible forms covers labels, error messages and validation in more detail.

Fix Content and Documents Alongside the Code

Content fixes should run alongside the template work, because many audit findings come from what editors publish rather than how the website is built. Missing alt text, vague link text, skipped heading levels and tables without header rows all sit in the content, so a developer cannot fix them once and walk away.

The GOV.UK guidance on making a website accessible says the people who edit a website have a responsibility to make new content accessible, from writing good link text to publishing accessible images, videos and documents. Editor training belongs in the remediation plan for that reason, alongside a short checklist editors can use before they publish.

Priority Pixels handles the technical code restructuring in its remediation work, while future content additions still need continued attention to accessibility guidelines. That split is worth agreeing with any supplier, so nobody assumes the other side is fixing the content.

Documents need the same treatment as web pages. A PDF that people must complete to use a service, such as an application form, should either be replaced with an accessible web page or fixed so it works with assistive technology.

Retest With Users and Assistive Technology

Retest every fix before marking it as done, then retest the website as a whole once the planned work is complete. GOV.UK guidance recommends a second audit once the fixes are made, so the budget for remediation should include that retest from the start.

Automated tools catch regressions quickly, but they cannot confirm that a fix works for a person using assistive technology. The GOV.UK Service Manual page on testing with assistive technologies lists the combinations services should work with, including the JAWS and NVDA screen readers, VoiceOver on iOS, TalkBack, screen magnifiers and Dragon speech recognition.

Testing with disabled people adds what technical checks miss. The W3C’s guidance on involving users in evaluating web accessibility says evaluating with disabled and older users identifies usability issues that conformance evaluation alone does not find. It also warns that results from a few people cannot be generalised to everyone, so user testing works alongside a WCAG check rather than replacing it.

Priority Pixels includes a free repeat audit after remediation work is delivered. Whoever carries out the work, the retest should be agreed before the fixing starts so it is never dropped when the budget runs short.

Update the Accessibility Statement

Update the accessibility statement as soon as the retest results are in, so it describes the website as it is now rather than as it was at the audit. Regulation 8 of the Public Sector Bodies Accessibility Regulations 2018 requires public sector bodies to keep their statement under regular review and to explain which content is not accessible and why.

The compliance status should change as the work progresses. GOV.UK describes a website as fully compliant when it meets the standard in full, partially compliant when it meets most requirements and not compliant when it does not meet most of them.

The sample accessibility statement published by GOV.UK includes the wording that is legally required and shows how to set out the problems that remain. Each fixed issue should come off the list of known problems and each remaining issue should keep a realistic date for its fix.

Our guide to writing an accessibility statement covers each section in detail, including how to describe content that is still not accessible. Private businesses are not legally required to publish a statement, although public sector and large enterprise buyers often ask for one during procurement.

Keep Accessibility From Slipping After Remediation

Accessibility slips back whenever new content, templates or plugins go live without being checked, so monitoring needs to become part of normal website work. GOV.UK guidance asks public sector bodies to make sure new content and features meet accessibility standards and to check that new features work with assistive technologies.

A light routine covers most of the risk. Automated scans on a schedule catch obvious regressions such as missing alt text or low contrast, while a manual check of key journeys after each release catches the keyboard and screen reader problems that scans miss.

Plugin and theme updates are a common source of new failures on WordPress websites, because a change to a form or slider plugin can undo a fix without anyone noticing. Ongoing WordPress support and maintenance that includes checking key journeys after updates keeps those regressions short lived.

The statement review gives the routine a fixed point in the calendar. Public sector bodies must review their statement after major changes and at least once a year, so pairing that review with a retest gives any organisation a sensible minimum.

An audit is a snapshot of one moment, while remediation and monitoring decide whether the website stays usable for the people who rely on it. Treating the report as the start of that work rather than the end of a project is what turns the findings into lasting improvements.