AODA Remediation: How the Actual Fix Work Gets Done

An audit tells you what’s broken. Remediation is the separate, slower job of actually going into the code and fixing it — and how that project gets scoped is what separates a punch list that gets acted on from one that sits in an inbox.

What is AODA remediation, and how is it different from an audit?

An audit tells you what’s wrong. Remediation is the separate work of going into your actual code and correcting it. They get talked about as one phase, “get audited,” but they’re two different jobs with two different deliverables, and mixing them up is how a business ends up with a punch list and nobody assigned to act on it.

The audit is diagnostic: a tester, using an automated scanner plus a manual keyboard and screen-reader pass, works through your site and produces a prioritized report tied to specific WCAG 2.0 AA success criteria. That process, and what a good report actually looks like, is covered in full in the website accessibility audit guide and the AODA audit checklist. Neither of those pieces goes deep on what happens after the report lands. This one does.

Remediation is where that report turns into shipped code. Alt text gets written, per image, by someone who looked at it. Contrast gets corrected in the CSS. A keyboard trap in a mega menu gets rebuilt with real focus management. It’s development work, billed and scheduled like development work, and it’s the part an audit alone never touches.

How does a remediation project actually get scoped and prioritized?

By severity first, then by how many pages a single fix actually touches, not by the raw count of line items an audit turned up. A 200-issue report sounds enormous until you notice 140 of those issues are the same broken dropdown menu, repeated across every page that uses it.

A workable severity framework, laid out clearly in accessible.org’s guide to building a remediation plan, sorts every finding into four tiers.

Layer that against your site’s actual templates, not its page count. A header, a footer, a shared form component, and a navigation menu usually appear on every single page. Fix the component once, correctly, and every page inheriting it is fixed with it. That’s the leverage a good remediation scope is built around: critical issues first, shared components before one-off page fixes, then the medium and low-priority cleanup once the parts that block real people are handled.

What does AODA remediation actually look like on a WordPress site?

It means going into the template, the theme’s components, and the media library, not a plugin’s settings panel. WordPress remediation touches four areas specifically, and each one needs its own pass.

• The theme and page builder. Divi, Elementor, and WPBakery generate a lot of div-based buttons, sliders, and menus that skip real semantic HTML, which is the structural work remediation has to redo. That’s covered in full depth, with the specific module-by-module failure patterns, in the AODA and WordPress guide; this piece won’t re-run that list.
• Plugins. Every interactive plugin, booking widgets, review sliders, custom forms, ships its own markup, and each one needs to be tested and fixed independently rather than assumed safe because the theme passed.
• The media library. WordPress doesn’t force an alt-text field, so remediation almost always includes an image-by-image pass writing real, specific alt text rather than accepting whatever got left blank or auto-filled.
• Forms. Contact and quote forms need every field tied to a real, coded label, and clear, specific error messages, not a placeholder standing in for one.

WordPress remediation and a WordPress migration or redesign are frequently the same project in disguise, because both already touch every template. If you’re weighing a rebuild anyway, folding WCAG work into it, rather than doing it twice, is worth reading up on in the WordPress-specific guide linked above.

Does installing an accessibility overlay count as remediation?

No. An overlay runs a script on top of your existing markup; remediation rewrites the markup itself. They’re not two versions of the same fix, one cheap and one expensive. Only one of them touches the code a screen reader or keyboard actually interacts with.

The FTC’s 2025 order against overlay vendor accessiBe, a $1,000,000 penalty for falsely claiming its widget could make any website WCAG-compliant, is about as official a confirmation of that distinction as exists. The full case, the lawsuit data, and why a bolted-on script can make a page actively worse, not just insufficient, is in does an accessibility overlay make your website AODA compliant? If a vendor is pitching a widget as your remediation, that pitch is the thing to push back on.

How long does an AODA remediation project actually take?

Anywhere from a few weeks to several months, and the site’s size and complexity, not the number of issues an audit lists, is what actually drives that range. A published phased approach from accessible.org puts critical issues, the ones blocking a real task for assistive-technology users, inside the first 30 days, high-priority issues by day 60, and medium/low-priority cleanup wrapped up by day 90.

Scaled against overall site size, TestParty’s published remediation timeline data puts a small site under 50 pages at roughly 4 to 8 weeks, a mid-size site in the 50-to-500-page range at 2 to 4 months, and a large or highly interactive site at 4 months or considerably more. A brochure site built on three templates and a component-heavy e-commerce catalogue simply aren’t the same job, even if they both get called “a website.”

Whatever the total, don’t compress it into a scramble against December 31, 2026. The step that gets skipped under time pressure is almost always the retest, and that’s exactly the step that catches a fix that looked right in code but didn’t actually work with a real screen reader.

What does AODA remediation cost, separately from the audit?

It’s priced off what the audit finds, not off a flat rate, because a report full of critical keyboard traps in custom components costs more developer time to fix than one full of missing alt text. Expect remediation to be quoted as its own line item, after the audit scopes the actual work, rather than bundled sight-unseen into the audit fee.

One comparison worth sitting with regardless of the exact number: a remediation project is a one-time cost. An overlay subscription is a recurring one that, over a year or two, adds up to roughly the same range as real remediation, except the subscription never actually fixes anything. The math behind that comparison is in the audit cost breakdown.

Audit vs. remediation vs. overlay: what’s the actual difference?

Line up the three things people conflate under “getting AODA compliant” and the distinction stops being abstract.

Only the middle column changes what a screen reader or a keyboard actually encounters. The other two either measure the problem or paper over it.

When should you hire someone for AODA remediation instead of doing it yourself?

A handful of fixable issues on a simple, template-light site is genuinely a DIY job if a developer on your team is willing to work through the list properly. Anything built on a heavy page builder, carrying custom interactive components, or serving as the compliance evidence behind a 50+ employee report is a different calculation.

Piecemeal fixes on a live site, module by module, whenever someone gets around to it, tend to cost more over time than scoping the whole remediation once and doing it properly. If you’re already planning a redesign or a platform move this year, that’s the cheapest point to fold this work in, since the project already touches every template anyway.

On any serious build, accessibility gets tested and signed off before launch, not patched in afterward when someone complains. That’s the bar I bring to a small Ontario business site too, the standard doesn’t change with the size of the client, only the scope of the work does. If you’d rather have someone scope and run the whole remediation, that’s what jbe.works accessibility does, code-level fixes, not a widget in the quote.

Where should you actually start with AODA remediation?

Get a real audit first, if you haven’t already, since remediation without one is just guessing at priorities. The AODA audit checklist walks through exactly what to test. Once you have findings in hand, group them by severity and template using the framework above before a single line of code changes.

If you’re on WordPress specifically, read the AODA and WordPress guide next for the builder-specific detail this piece deliberately didn’t repeat. And if a vendor’s already pitched you an overlay as the fix, this is why it isn’t one. Ready to have someone scope and run the actual remediation? jbe.works accessibility is built around exactly that, and a free scan is one message away at contact.

Frequently asked questions

Quick answers to what comes up most once an Ontario business moves from “we got audited” to “now what.”

What’s the difference between an accessibility audit and remediation?

An audit tests your site and documents what fails WCAG 2.0 AA. Remediation is the separate work of a developer actually fixing those failures in the code. An audit alone never changes what a screen reader or keyboard encounters.

How is a remediation project prioritized?

By severity first, critical issues that block a task entirely before cosmetic ones, then by template, since fixing a shared component like a header or form once usually fixes it across every page that uses it, rather than working page by page.

How long does AODA remediation take?

It scales with site size and complexity: roughly 4-8 weeks for a small site, 2-4 months for a mid-size one, and 4 months or more for a large or highly interactive site, with critical fixes typically prioritized inside the first 30 to 60 days.

Does an accessibility overlay count as remediation?

No. An overlay adds a script on top of your existing code without changing the underlying markup, so it doesn’t move you toward genuine WCAG 2.0 AA conformance. Remediation means editing the actual template and component code.

What does AODA remediation look like on a WordPress site?

Rebuilding theme and page-builder components as real semantic HTML, testing every plugin’s markup individually, writing alt text by hand in the media library, and tying every form field to a real coded label, none of which a plugin can do after the fact.

When should I hire someone for AODA remediation instead of doing it myself?

Once your site is built on a heavy page builder, carries custom interactive components, or the fix needs to hold up as evidence behind a 50+ employee compliance report, a professional remediation project is usually cheaper and safer than piecemeal in-house fixes.