AODA Compliance for WordPress: Why an Accessibility Plugin Isn’t Enough

Divi, Elementor, and WPBakery weren’t built to pass WCAG, and no plugin bolted on afterward can rebuild the markup they already shipped.

Does installing an accessibility plugin make my WordPress site AODA compliant?

No. Not on its own, and not by a comfortable margin either. WordPress accessibility plugins split into two camps, and neither one rewrites the markup underneath your theme.

The first camp is the overlay widget, a floating icon that drops in a panel of toggles: bigger text, higher contrast, a “screen reader mode.” The second is the toolkit plugin, the kind that adds skip links and a contrast checker to your dashboard. Both run after your theme or builder has already rendered the page. They can nudge a font size or inject an ARIA attribute at runtime, but they cannot retroactively turn a decorative div onclick element into a real, focusable button. The structure was already baked when the plugin woke up.

This isn’t a fringe opinion. The FTC ordered accessiBe to pay $1,000,000 in a case that closed in April 2025, for falsely marketing its accessWidget as something that could make any website WCAG-compliant, on top of disguising paid reviews as independent ones (FTC.gov). W3C’s Web Accessibility Initiative and the Overlay Fact Sheet, signed by 900+ accessibility practitioners, say the same thing in plainer language: automated overlays catch a minority of real issues and cannot achieve full conformance. If you want the deeper version of that argument, with the lawsuit numbers, it’s covered in does an accessibility overlay make your site AODA compliant?. Short version for WordPress specifically: the plugin isn’t lying about being helpful. It’s lying about being sufficient.

Why do WordPress themes and page builders ship inaccessible markup by default?

Because Divi, Elementor, and WPBakery are sold on visual flexibility, and unrestricted visual flexibility is close to the opposite of the discipline that produces clean, accessible markup. A theme or builder can ship a design in an afternoon; it can’t ship the ongoing checking — every module, tabbed through, listened to with a screen reader — that developers shorthand as a11y. a11y vs WCAG vs AODA, untangled covers where that word fits next to the standard and the law, if you want the short version.

A handful of patterns show up constantly across page-builder output.

• Heading modules. A heading module lets you pick any size for any block, so a page ends up jumping from an H2 straight to an H5 because that’s what looked right in the editor, not because it reflects a real document outline.
• Div-based buttons. A “button” module is frequently a styled div or span with a click handler, not a real button or a element, which means keyboard users tabbing through the page skip right over it.
• Sliders. Testimonial and hero sliders auto-rotate with no pause control and no keyboard arrows wired up.
• Hamburger menus. Off-canvas hamburger menus open on click but don’t trap or return focus properly, so a keyboard user can tab straight through the menu and out into content behind it.
• Image modules. Image modules don’t force an alt-text field, so plenty of images ship with an empty alt attribute or none at all.
• Colour palettes. The demo colour palettes those builders ship with are chosen to look good in a marketplace screenshot, not to clear a 4.5:1 contrast ratio.

None of that is a guess. WebAIM’s WebAIM Million report, run against one million real home pages in February 2026, found 252,302 of that sample built on WordPress, averaging 52.8 accessibility errors per page, only a shade better than the million-page average of 56.1. That’s WordPress across every theme and builder combined, and it’s still failing WCAG almost everywhere. Run of the mill WordPress, built on exactly the themes and builders described above, is the norm, not the exception.

What’s the actual difference between an accessibility plugin and proper WCAG remediation?

One patches the browser after the fact. The other rebuilds what actually gets sent to the browser. Here’s the comparison I’d put in front of a client weighing the $50-a-month widget against a real fix.

Read down that right-hand column and you’ll notice none of it is a settings panel. It’s all code.

What does a WordPress site actually need to meet WCAG 2.0 AA?

Five things, none of them optional, all of them living in the template rather than a plugin settings screen. Ontario’s IASR s.14 sets the bar at WCAG 2.0 Level AA specifically, not 2.1 or 2.2, with a standard exception carved out for live captions (1.2.4) and audio description (1.2.5).

A semantic template. One logical heading order (H1 then H2 then H3, no skipping levels because a module defaulted to a different size), plus real nav, main, and footer landmarks a screen reader can jump between.

Real alt text. Every image that carries meaning gets a short, specific, human-written description. Purely decorative images get an empty alt attribute on purpose, so a screen reader skips them instead of reading a filename aloud.

Keyboard-operable everything. Menus, sliders, accordions, and modals all need to be reachable by Tab, show a visible focus outline, and operate with Enter, Space, or the arrow keys, the way a real HTML element behaves by default and a styled div does not.

Contrast that clears the bar without help. 4.5:1 for normal text, 3:1 for large text and interactive components, baked into the default design tokens, not a high-contrast mode the visitor has to discover.

Labelled forms and clear names. Every input tied to a real coded label, every link and button described by text that makes sense out of context, so “click here” and a bare icon with no accessible name both get replaced.

Anchor all of this against W3C’s WCAG guidance and its four POUR principles: Perceivable, Operable, Understandable, Robust. Everything above maps to one of those four.

Can a plugin fix a page builder’s broken markup after the fact?

Not the structural stuff, no. A plugin runs in the browser once the builder has already rendered its output, and by then the die is cast. It can add a skip link at the top of the page. It cannot go back and give a click-only slider real keyboard arrows, because that behaviour has to be coded into the component, not sprayed on top of it in a script tag.

Worse, a plugin that tries to patch ARIA (the code labels that tell screen readers what an element is) attributes onto markup the builder never designed for it often makes things actively worse. The standing rule among accessibility engineers is blunt: “no ARIA is better than bad ARIA.” An aria-expanded attribute injected onto a div that has no real expand behaviour, or a role of button slapped onto something with no keyboard handler, tells a screen reader user something is interactive when it isn’t, which is a worse experience than saying nothing at all.

And the overlay industry’s own numbers back this up. UsableNet’s 2025 year-end report counted more than 5,000 digital-accessibility lawsuits filed that year, roughly 70% against e-commerce sites, with a growing share targeting sites that already had an overlay or widget installed. Bolting a script onto broken markup doesn’t just fail to fix it. It can hand you a false sense of having handled it.

What does real WordPress accessibility remediation actually look like?

It looks like a code project, because it is one. Real remediation means going into the template and component files, not the plugin directory, and it usually breaks down into the same handful of jobs regardless of which builder you’re untangling.

• Rebuilding menus, buttons, and toggles as real semantic elements with native keyboard support, instead of styled divs with a click handler.
• Writing alt text by hand, image by image, rather than accepting whatever the media library auto-generated.
• Fixing the colour palette at the design-token level so contrast passes by default, not behind a toggle.
• Wiring every form field to a real, coded label rather than a placeholder pretending to be one.
• Restructuring headings into one coherent hierarchy across the whole template, not per-block guesswork.
• Testing with an actual keyboard-only pass and a screen reader like NVDA or VoiceOver, not just running an automated scanner and calling it done.

An automated scanner is a starting point. It is not the finish line. Manual testing with real assistive technology is the part every credible standards body, W3C included, insists can’t be skipped.

How does headless WordPress solve the theme and builder problem?

It hands you full control of the exact markup that gets rendered, instead of whatever a locked-down builder decides to output on any given page. That’s the whole trade.

In a headless build, WordPress and WPGraphQL become the content store, editors keep the exact dashboard they already know, while a hand-built Next.js frontend owns every button, nav, carousel, and form as a coded component. You write the accessible version of a component once, in a shared component library, and every page that uses it inherits the same keyboard behaviour, the same labelling, the same contrast — in plain terms, every button and form is accessible by construction, and stays that way when your staff add a page next year. There’s no builder shortcut sitting one click away that quietly reintroduces a div pretending to be a button, because that option doesn’t exist in the component set at all. It’s exactly the kind of markup control that page builders are architecturally unable to offer, because their entire product is “anyone can drop in any module,” and accessible-by-construction requires the opposite promise.

I’ll say plainly where this comes from. Across Postmedia’s 13-plus newspaper blogs on WordPress VIP, every property had to clear VIP’s own release bar before anything shipped, accessibility included — there was no “patch it after launch” option. The Sportsnet.ca migration ran the same way: a national broadcaster’s legal team doesn’t sign off on “mostly accessible.” A contractor’s site in Cambridge doesn’t face that kind of release gate, but a headless Next.js and WPGraphQL build, the exact stack jbe.works runs, is how that same level of markup control shows up at SME scale, without needing an enterprise VIP budget to get it.

Is a migration or rebuild the right time to fix WordPress accessibility?

Yes, and it’s usually the cheapest point in the whole project to do it. Remediating a page builder’s markup piecemeal, module by module, on a live site tends to cost more over time than fixing it once while you’re already rebuilding the templates for another reason.

If you’re already working through a WordPress migration, new host, new domain, or leaving another platform for WordPress, that project already touches every template. Baking WCAG 2.0 AA into the rebuild costs a fraction of retrofitting it afterward. One thing worth knowing before you reach for a shortcut: running a straight migration plugin moves your files and database byte for byte to the new server. It transports your existing Divi or Elementor markup exactly as-is. It does not touch a single div, so a plugin-only migration is a clean opportunity to fix accessibility, wasted. And if the plan is to go further, a full headless Next.js rebuild, that’s the project where “migrate” and “remediate” become genuinely the same line item, not two separate invoices.

What’s the December 31, 2026 deadline, and does it force me to fix my WordPress site?

It depends entirely on your Ontario employee count, and the two obligations aren’t the same thing. Businesses and non-profits with 20 or more employees must file an accessibility compliance report by December 31, 2026 through the Accessibility Compliance Reporting Portal, per ontario.ca. That’s the filing duty, and it applies whether or not your website itself is fully conformant.

The website duty is a separate, higher bar. Under IASR s.14, it only attaches at 50 or more employees, the threshold Ontario defines as a “large organization.” At that size, the law is direct: you must make all public websites accessible, on top of the report, documented and posted policies, and a multi-year accessibility plan. Under 50 employees, you file the report if you’re at 20+, but you are not legally required to make the website WCAG-conformant. The full threshold breakdown, with worked examples, lives in the pillar guide, AODA website requirements for Ontario businesses.

What should I actually do about my WordPress site’s accessibility?

Start with an honest audit, and make sure a human, not just an automated scanner, actually looks at it. Scanners catch contrast and missing alt text reliably. They miss keyboard traps, focus order problems, and screen-reader experience almost entirely, which is exactly the gap manual testing exists to close.

From there it’s a sizing question. A handful of fixable modules on a site you’re keeping might genuinely be a piecemeal job. A site built entirely on a heavy page builder, carrying years of accumulated modules, is usually cheaper to remediate once, properly, than to chase module by module. And if you’re touching the site for any other reason this year, new host, a redesign, leaving another platform, that’s the moment to fold accessibility into the same build instead of paying for it twice.

If you want a second opinion on which bucket your site falls into, that’s exactly the kind of scoping conversation web design covers, no obligation attached, or just get in touch directly.

Frequently asked questions

Quick answers to the questions that come up most about AODA, WCAG, and WordPress.

Does an accessibility plugin make my WordPress site AODA compliant?

No. Overlay widgets and toolkit plugins run after your theme has already rendered the page and can’t rewrite div-based buttons, broken heading order, or keyboard traps into real semantic markup. The FTC fined accessiBe $1,000,000 in 2025 for claiming its widget alone could make sites WCAG-compliant.

Why do WordPress themes and page builders fail WCAG by default?

Divi, Elementor, and WPBakery are built for visual flexibility over structural discipline. That produces skipped heading levels, div-based buttons with no keyboard support, auto-rotating sliders with no pause control, and colour presets chosen for looks, not contrast.

Can I fix Divi, Elementor, or WPBakery’s accessibility problems with CSS alone?

Not the structural problems. CSS can fix contrast and spacing, but keyboard operability, focus management, and semantic element types have to be coded into the component itself, which usually means custom development beyond the builder’s own settings.

What does a WordPress site need to meet WCAG 2.0 AA?

A semantic template with a logical heading order, real hand-written alt text, fully keyboard-operable menus and interactive components, 4.5:1 contrast (3:1 for large text), and form fields tied to real coded labels. That’s the standard set under Ontario’s IASR s.14.

Does headless WordPress fix accessibility problems automatically?

Not automatically, but it removes the barrier. A Next.js frontend over WPGraphQL means every component is hand-coded once and reused, so there’s no page-builder shortcut that can silently reintroduce inaccessible markup. The accessibility work still has to be done, deliberately, in the component library.

Should I fix accessibility before or during a WordPress migration?

During, if you can. A migration or rebuild already touches every template, so folding WCAG 2.0 AA remediation into that project costs a fraction of retrofitting it later. A plugin-only migration, by contrast, moves your existing inaccessible markup unchanged to the new server.