By Mehdi HassanHow do you fix accessibility issues on an existing website?
You fix accessibility issues on an existing website by working from an issue list, not from a hunch, and by fixing causes instead of symptoms. The order that works: inventory every issue, group them by the component or template that causes them, rank the groups by risk and effort, then fix them in short sprints with a retest after each one.
The aim is a site that meets WCAG 2.2 Level AA on the pages and tasks that matter, with evidence to show it. The legal context, including the ADA and the European Accessibility Act, is in our hub on website accessibility compliance. This guide is the practical plan for getting an existing site there.
What does accessibility remediation involve?
Accessibility remediation involves changes in three places: design (colors, focus styles, sizes, layout), code (semantics, keyboard behavior, ARIA, focus management) and content (alt text, headings, link text, labels, captions). Most remediation projects touch all three, which is why teams where one person or group owns only one of them tend to stall.
Layer | Typical fixes | Who does it |
|---|---|---|
Design tokens | Text and UI colors that pass contrast, focus ring style | Designer |
Components | Buttons, forms, menus, modals, tabs, carousels | Developer with designer |
Templates | Heading order, landmarks, skip link, reading order | Developer |
Critical flows | Signup, checkout, booking, account settings | Developer and QA |
Content | Alt text, link text, captions, plain-language errors | Writer or editor |
Third-party embeds | Chat, scheduling, cookie banners, video players | Whoever owns the vendor |
Documents | PDFs and downloads | Writer, or replace with HTML pages |
Remediation does not involve installing an overlay widget. As we explain in do accessibility overlays work?, a script on top of broken code leaves the code broken.
How do you build the accessibility issue list?
Build the issue list from three sources: automated scans of every template, manual keyboard and screen-reader testing of every key flow, and an expert audit if you need documented evidence. Each source catches problems the others miss. Record every issue in one place with its location, WCAG criterion, severity and a screenshot.
- Scans find contrast failures, missing alt text, missing labels and empty links quickly.
- Manual testing finds focus traps, broken focus order, confusing announcements and unusable custom widgets.
- An audit adds expert judgment and a report you can show buyers. Our guide to accessibility audit cost covers scoping.
- User reports belong in the list too. Complaints through your contact form or statement are high-value findings.
Then group by root cause. Tag each issue with the component or template it comes from. A list of hundreds of findings often turns into a short list of shared causes, and that short list is what you plan against. Use our WCAG 2.2 checklist to make sure every criterion has been looked at.
How do you prioritize WCAG remediation?
Prioritize WCAG remediation by risk first and effort second. Risk means how badly an issue blocks people and how exposed it makes you; effort means how much design and development time the fix takes. Anything high-risk gets fixed early regardless of effort, and anything low-effort gets bundled in alongside, so progress shows quickly.
Risk / effort | Low effort | High effort |
|---|---|---|
High risk | Do first: labels on checkout fields, focus styles, alt text on product images | Plan now: rebuild an inaccessible menu, replace a booking embed |
Low risk | Batch in: link text, heading levels on old posts | Schedule later or retire: legacy PDFs, archived microsites |
High risk usually means a blocker in a flow where people spend money, sign up, book or get support, or a problem on every page, like the main navigation. That's where US lawsuits tend to focus, as our guide to ADA website compliance explains, and where users give up.
What order should you fix accessibility issues in?
Fix accessibility issues from the foundation up: design tokens, then shared components, then critical flows, then templates, then content, then third parties. Each layer makes the next one smaller, because pages built from fixed components inherit the fixes.
Fix the design tokens
Adjust text and UI colors to pass contrast and define one visible focus style. These changes cascade through the whole site at once.
Fix shared components
Buttons, links, form fields, error messages, navigation, modals, accordions, tabs and carousels. Use native HTML elements where possible and add correct names, roles and states.
Walk the critical flows
Test signup, checkout, booking and contact end to end with a keyboard and screen reader, and fix anything still blocking.
Fix template structure
Heading order, landmarks, a skip link, page titles and reading order on each template.
Do a content pass
Alt text, link text, captions and transcripts. Make alt text a required CMS field so new content stays fixed.
Deal with third parties
Ask vendors for accessibility reports, configure what you can, and replace embeds that can't be fixed.
Retest and document
Retest each fixed area, close issues in your log and update your accessibility statement with what's still known.
How do you run remediation in sprints?
Run remediation in short, fixed sprints, each with a clear scope and a retest at the end. Sprints make the work predictable, show progress to anyone watching, and stop remediation from dragging on as an open-ended background task that never finishes.
Hypothetical example: a three-sprint remediation plan
For example, suppose a B2B SaaS company has a 20-page marketing site, a demo-request form and a self-serve signup, and an audit has been grouped into causes.
Sprint one fixes design tokens and the most-used components: color contrast, focus style, buttons, form fields and errors, and the navigation menu. It ends with a keyboard and screen-reader retest of signup and demo request.
Sprint two fixes templates and remaining components: heading structure, skip link, modals, the pricing toggle and the testimonial carousel's pause control. Content editors add alt text in parallel.
Sprint three handles third parties and leftovers: replacing the cookie banner, fixing the embedded scheduler or providing an alternative, captioning product videos and updating the statement. Each sprint's scope is agreed at the start, and nothing ships without a retest. This is an illustration of the approach, not a real project.
This is the kind of work our retainer suits. A retainer team takes the prioritized list, works through it sprint by sprint alongside your other design and development needs, and retests as it goes, without hourly tracking.
Should you remediate or rebuild your website?
Remediate when the site's structure is sound and issues live in a manageable number of components. Rebuild when the platform or code fights every fix: page builders that generate inaccessible markup you can't control, a theme with no component system, or a site you were planning to redesign within a year anyway.
Pros
- Remediation keeps your URLs, content and SEO history intact
- It can start immediately and show progress quickly
- Spreads cost over sprints instead of one large project
Cons
- Fragile code or page builders can make each fix slow and repetitive
- You may fix components a planned redesign will replace anyway
- Hard limits, like a platform's own inaccessible widgets, may remain
If you do rebuild, protect your search traffic: our guide to why traffic drops after a website migration covers redirects and checks. And make sure you'll actually control the new code and hosting; the website ownership checklist covers that.
How do you keep a remediated site accessible?
Keep a remediated site accessible by making accessibility part of how new pages are built and approved. Most sites drift back into failure through new content, campaign pages and third-party tools, not through changes to fixed components.
- Accessible CMS blocks. Editors build pages from tested components. If your team struggles with the editor, see why your marketing team can't edit the website.
- Required fields. Alt text and heading levels enforced in the CMS.
- A keyboard pass in QA for every new page and feature.
- Monthly scans of key templates to catch regressions early.
- Vendor checks before any new embed goes live.
