How to Fix Accessibility Issues: A Practical Remediation Plan

To fix accessibility issues for good, find them with a scan plus manual checks, rank them by how badly they block people, repair them in your site’s own code, retest with a keyboard and assistive technology, and then recheck on a schedule. This guide walks through each step in that order, with the fixes for the most common problems and a roadmap you can adapt for a small team.

The work is manageable. Most sites share a short list of recurring problems, and a clear plan turns a long report into a series of small, finished tasks.

TL;DR

• Start with a baseline: an automated scan, then a manual pass with a keyboard and a screen reader, because automation alone cannot judge a whole site.
• Prioritize by impact: fix anything that blocks a task (checkout, forms, navigation) before cosmetic findings, and fix issues that repeat in templates first.
• Repair in the source code (markup, styles, templates), not with a runtime patch, so the fix survives redesigns and updates.
• Retest every fix, then keep rechecking. Updates and new content introduce regressions.
• Keep dated records of scans, fixes and your accessibility statement as evidence of ongoing effort.

Table of Contents

• What “remediation” actually means
• Which standard are you fixing against?
• Step 1: Build a baseline you can trust
• Step 2: Prioritize the findings
• Step 3: Fix the common issues in the code
• Step 4: Test that the fixes work
• Step 5: Turn it into a roadmap
• Perspective: why we favor permanent fixes
• How AccessWiser supports the process
• Common mistakes to avoid
• FAQ
• Sources

What “remediation” actually means

Remediation is the process of finding accessibility barriers and correcting them so people who use keyboards, screen readers, magnification, voice control or other assistive tools can complete the same tasks as everyone else. It is not a one-time project. The University of Virginia’s digital accessibility team describes it as an iterative, ongoing process that needs re-testing after updates or content changes, so new code or content does not bring problems back.

That framing matters for planning. A remediation plan has a start (the audit and the first round of fixes) and a rhythm (checks that repeat). Teams that treat it as a single cleanup tend to find the same problems again after the next redesign.

Which standard are you fixing against?

Most teams use the Web Content Accessibility Guidelines (WCAG) at Level AA as the target. In the United States, two legal frameworks point there in different ways:

• Section 508 applies to federal agencies and their ICT. The Access Board explains that the 508 Standards incorporate WCAG 2.0 Level AA by reference.
• The ADA is enforced by the Department of Justice for many businesses and public entities. A 2021 settlement agreement with the Champaign-Urbana Mass Transit District required WCAG 2.1 AA and a designated Web Accessibility Coordinator. That is one agreement with one entity, but it shows how enforcement tends to reference WCAG.

WCAG 2.2 AA is a practical target because it includes the earlier success criteria and adds newer ones. If you want the legal background in plain language, our guide to ADA versus WCAG explains how the two relate, and our breakdown of WCAG and Section 508 covers the federal side.

Step 1: Build a baseline you can trust

You cannot prioritize what you have not measured. A baseline has two layers.

Automated scanning

An automated scan covers a large number of pages quickly and ties each finding to an element and a success criterion. It reliably catches things a machine can verify: missing alt attributes, empty buttons and links, form fields without programmatic labels, missing page language, and many contrast failures.

It cannot tell you whether alt text is meaningful, whether the reading order makes sense, or whether a custom widget is usable with a screen reader. The Access Board says plainly that a mix of manual and automated testing is often needed to fully evaluate most websites. Treat a clean scan as a good sign, never as proof of conformance.

Manual checks

The UK Department for Work and Pensions publishes basic accessibility checks that a non-specialist can run. Its list of frequent problems includes insufficient color contrast, missing or inaccurate image alt text, improper heading hierarchy, and missing visible focus for keyboard users. Run through these on your most important pages:

1. Unplug the mouse and tab through the page. Can you reach and operate everything? Can you always see where focus is?
2. Zoom the browser to 200 percent. Does anything overlap or disappear?
3. Read the headings in order. Do they outline the page?
4. Open a screen reader on one key flow, such as checkout or a booking form.

If you want to see how combining automated and human review works in practice, this overview of web accessibility and SEO impact discusses pairing tools with manual evaluation. If your site runs on WordPress, this WordPress accessibility guide for agencies covers the platform-specific side.

Pick a sample of pages that represent each template: home page, a content page, a product or service page, a form, and a checkout or booking flow. Fixing a template fixes every page built on it.

Step 2: Prioritize the findings

This is where most remediation plans stall. A first scan can return hundreds of items, and treating them all as equal leads to paralysis. Use three questions to sort them.

Does it block a task? A checkout button that a keyboard cannot reach, or a form field a screen reader announces as “edit text” with no label, stops someone from buying or booking. These come first.

How many pages does it affect? One missing label in a shared header or footer template appears on every page. Fixing it once removes hundreds of findings from your report.

How hard is the repair? Adding a language attribute takes a minute. Rebuilding a custom date picker takes days. Quick wins build momentum, but do not let them push aside a hard blocker.

A simple tiering works well for small teams:

Adjust the tiers to your business. A restaurant should put online ordering and reservation forms at the top. A law firm should start with contact forms and key practice-area pages. An online store should begin with product pages, cart and checkout; our guide to finding and fixing checkout traps covers that flow in detail.

Step 3: Fix the common issues in the code

The repairs below cover the problems that show up on most sites. Make each change in the source (theme, template, component or content editor), so it stays fixed.

Color contrast

Text must have enough contrast against its background. WCAG AA asks for a ratio of at least 4.5:1 for normal text and 3:1 for large text. Change the color values in your stylesheet or design tokens rather than overriding one element at a time, so every use of that color is corrected together.

Also check that color is not your only signal. Accessibility checklists, including one from the American Heart Association, flag relying on color alone, such as marking required fields only in red, as a failure. Add text such as “required” or an icon with a text label.

Image text alternatives

Every meaningful image needs an alt attribute that says what the image communicates in context, not just what it looks like. A photo of a dental chair on a clinic’s services page might say “Treatment room with adjustable dental chair”. Purely decorative images should have an empty alt attribute (alt="") so screen readers skip them. Images that act as links or buttons need alt text that describes the destination or action.

Form labels

Every input needs a visible label that is programmatically connected to it:

<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email">

A placeholder is not a label, because it disappears when someone types. Group related fields, such as radio buttons, in a fieldset with a legend. Write error messages that name the field and say how to fix it, and make sure they are announced to assistive technology.

Empty links and buttons

An icon-only button, such as a magnifying glass or a cart, needs an accessible name. Visible text is the best option. If the design truly requires an icon only, add an aria-label that matches what the button does. Links that read “click here” or “read more” should say where they lead, because screen reader users often navigate by a list of links.

Page language

Set the lang attribute on the html element (for example <html lang="en">) so screen readers pronounce content correctly. If a passage is in another language, mark that passage with its own lang attribute. In most site builders and WordPress themes this is a single setting, so check it first.

Keyboard access and visible focus

Everything you can do with a mouse must work with a keyboard, and the focus indicator must be visible. The most common cause of lost focus styling is a CSS rule that removes the outline. Replace it with a clear style rather than deleting it:

:focus-visible {
  outline: 3px solid #1a1a1a;
  outline-offset: 2px;
}

Use real buttons and links instead of clickable div elements, because native elements come with keyboard behavior built in. For menus, dialogs and tabs, test that focus moves where users expect and can always escape. Our seven-step keyboard guide walks through this, and our piece on accessible tabs shows where scanners miss problems.

Headings and structure

Use headings to outline content, not to make text bigger. One H1, then H2s for main sections, and H3s beneath them. Skipped levels and decorative headings confuse people who navigate by headings.

Time limits

If your site logs people out or expires a cart, provide a way to extend the time without losing their data. The DWP manual notes that WCAG 2.2 criteria on session timeouts call for this. Booking and checkout forms are where it matters most.

Documents

PDFs such as menus, price lists and forms need their own fixes: tags, reading order, alt text and form field labels. If you can, publish the same content as an HTML page. Otherwise see our guide to fixing PDF accessibility.

Step 4: Test that the fixes work

A fix is finished when it works for a person using assistive technology, not when the scanner turns green. After each batch of changes:

1. Rescan the affected pages to confirm the finding is gone and no new one appeared.
2. Repeat the manual check that exposed the problem: tab through the page, zoom, or run the flow with a screen reader.
3. Record what you changed, the date, and who verified it.

If your team works in code, build checks into the pipeline. Our three-part WCAG 2.2 testing workflow shows how to run checks in CI/CD, and our guide to accessibility testing for developers covers shipping fixes quickly.

For federal and Section 508 work, the Access Board’s ICT Testing Baseline offers standardized test components. It is a set of components for evaluation, though, and not a step-by-step procedure, so you still need to decide how your team will run the tests.

Step 5: Turn it into a roadmap

People searching for an accessibility roadmap usually want a sequence they can put on a calendar. Here is one that fits a small team. Adjust the durations to your size and the number of templates.

Two habits keep the roadmap alive. First, name an owner, whether that is a developer, a marketing manager or the business owner. The DOJ settlement mentioned above included a designated coordinator for a reason: someone has to be responsible. Second, tie accessibility to your release process. The University of Virginia advises revisiting content regularly, taking in user feedback and testing after updates, which maps neatly to a recurring task in your calendar.

Perspective: why we favor permanent fixes

We built AccessWiser around one belief: accessibility improves when each problem is traced to the element and the success criterion it affects, and then repaired in the site’s own code. A fix in the source stays put through redesigns, plugin updates and new pages. A runtime patch that rewrites the page in the browser leaves the underlying problem in place.

We are also direct about what automation can do. Automated checks detect a substantial subset of barriers, and that is valuable, because they cover many pages and repeat on a schedule. They do not establish that a site is fully accessible, and we do not claim they do. We pair them with plain-language guidance so a small team without a dedicated specialist can understand what to change, and with dated records so you can show what you found, what you fixed and when.

The businesses that make the most progress are not the ones with the biggest budgets. They are the ones that start with the issues that block people, fix them properly, and keep checking.

— The AccessWiser Team

How AccessWiser supports the process

AccessWiser scans against WCAG 2.2 AA with Section 508 and EN 301 549 mappings, shows each issue with its element and criterion, and gives plain-language instructions for fixing it in your code. Scheduled re-checks catch regressions, and dated records of scans, fixes and your accessibility statement build your documentation as you go. An optional visitor widget lets people adjust contrast, text and motion to their own preferences, though it complements code fixes and never replaces them.

Plans on the pricing page are Starter at $24 per month, Basic at $49 per month and Pro at $119 per month. The Business plan has no published price. Extra specific page scans cost $12 one-off and extra full site scans cost $19 one-off. Every subscription starts with a 7-day free trial, so you can run a baseline scan on your own site before you commit. You can also start from the AccessWiser home page.

Common mistakes to avoid

• Fixing by page instead of by template. You will repeat the same fix dozens of times and miss the cause.
• Treating a passing scan as a finished job. Automated tools miss meaning, order and usability.
• Adding ARIA before fixing the HTML. Native elements are usually more robust than custom roles.
• Skipping retests. Each fix can break something nearby.
• Leaving content editors out. New images, links and PDFs reintroduce problems unless the people publishing them know the basics.
• Having no record. If a complaint or demand letter arrives, dated evidence of your scans and fixes helps you show a good-faith, documented effort.

FAQ

How long does it take to fix accessibility issues on a website?

It depends on the number of templates and how complex your custom components are. Many small sites can clear their blockers and the most common repeating issues in a few weeks, because fixes made once in a template spread across all pages. Custom widgets, complex checkout flows and large PDF libraries take longer. Plan for ongoing maintenance either way.

Can I fix accessibility issues without a developer?

Some of them, yes. Alt text, headings, link text, page titles and document structure are often content changes you can make in your editor. Contrast, focus styles and form markup usually live in the theme or template, which may be adjustable through your platform’s settings or may need a developer. Clear, plain-language guidance for each finding helps you decide which is which.

Does an accessibility widget or overlay fix my site?

No. A widget that lets visitors adjust contrast, text size or motion can help individual users, but it does not repair the underlying code. Automated tools and overlays also cannot fully evaluate a site on their own, since manual testing is often needed. Fix the source code first and treat a widget as an extra.

What should I fix first?

Start with anything that stops someone from completing a core task: keyboard access to menus, forms and checkout, labels on form fields, and buttons with no accessible name. Then fix repeating template issues, then contrast and focus visibility, then content details such as alt text.

How do I keep my site accessible after the fixes?

Rescan after releases and content changes, keep a short accessibility checklist for anyone who publishes, and review the results on a regular schedule. Keep dated records of what you found and fixed, and publish an accessibility statement with a way for visitors to report problems.

Sources

• Basic accessibility checks, DWP Accessibility Manual
• AHA digital content accessibility checklist
• ICT Testing Baseline Portfolio, U.S. Access Board
• Foundations of Accessibility Remediation, University of Virginia
• U.S. Access Board launches new site for the ICT Testing Baseline
• Settlement Agreement between the United States and the Champaign-Urbana Mass Transit District

Recommended

• SEO and Accessibility: A 90 Day Plan for Fixes That Help Both
• Fix PDF Accessibility for Dev Teams With Exact Code Changes
• 7 Steps for Developers to Test and Fix Keyboard Accessibility
• Ship Fixes Fast: WCAG 2.2 AA Accessibility Testing for Developers

Articles on this blog are general information about web accessibility, not legal advice. Laws change and their application depends on your specific situation — for decisions with legal consequences, consult a qualified legal professional.