Canadian compliance
AODA and WCAG compliance for WordPress
Ontario's accessibility legislation sets the obligation. WCAG sets the technical test. WP Doctor™ tests WordPress themes, page builders and forms against that test and documents what fails.
Not legal advice. This page is technical information about web accessibility on WordPress. It is not a legal opinion, and nothing here establishes that a site conforms to WCAG or meets the AODA. For your own obligations, consult a lawyer.
[WPDOCTOR_LEGAL_REVIEW_COMPLIANCE]
Who AODA applies to and at what thresholds
The web requirement in section 14 of Ontario Regulation 191/11 applies to designated public sector organizations and to large organizations, defined as those with 50 or more employees in Ontario. Since January 1, 2021, their internet websites and web content must conform with WCAG 2.0 Level AA, except for live captions and pre-recorded audio description.
The section covers websites and web content an organization controls directly or through a contract that allows modification, and content published after January 1, 2012. It applies except where meeting it is not practicable.
Organizations with fewer than 50 employees in Ontario are outside section 14. They remain subject to other parts of the regulation, including accessible feedback processes and accessible formats on request.
Businesses and non-profits with 20 or more employees file an accessibility compliance report every three years. The current deadline is December 31, 2026. A director can order compliance and an administrative penalty. Failing to comply with an order is an offence, with fines of up to $100,000 per day for a corporation.
What WCAG Level AA actually requires
WCAG 2.0 Level AA means meeting all 38 success criteria at Level A and Level AA, grouped under four principles: perceivable, operable, understandable and robust. Conformance is assessed for full pages and cannot be achieved if part of a page is excluded. The regulation names version 2.0. Later versions add criteria it does not reference.
The criteria are specific and testable. Text needs a contrast ratio of at least 4.5:1. All functionality must work from a keyboard, focus must never be trapped, and the focus indicator must be visible. Form inputs need labels or instructions. Every interface component needs a name and role that assistive technology can read. Content that conforms to WCAG 2.2 also conforms to 2.0.
Ten failures we see in WordPress themes out of the box
The ten failures below are WCAG 2.0 Level A and AA criteria that WordPress themes and their bundled plugins often miss in their default state. Each can be confirmed on a live page with a keyboard, a contrast checker and a screen reader. Each finding is recorded with the page, the element and the criterion.
- Body, placeholder or button text below 4.5:1 contrast (1.4.3).
- Focus indicator removed with
outline: none(2.4.7). - Form fields that use placeholder text in place of a label (3.3.2).
- Heading levels chosen for size, not structure (1.3.1).
- Dropdown menus and modals that cannot be operated or exited by keyboard (2.1.1, 2.1.2).
- Images and icons with no text alternative (1.1.1).
- "Read more" and "click here" links with no context (2.4.4).
- No skip link past the navigation (2.4.1).
- Form errors that are not described in text (3.3.1).
- Icon-only buttons with no accessible name: menu toggles, search, carousel arrows (4.1.2).
Why accessibility overlay widgets are not compliance
An overlay widget is a third-party script that adds a toolbar and attempts to patch the page in the visitor's browser. It is not a substitute for conformance. The regulation requires the website and its web content to conform with WCAG 2.0 Level AA. An overlay leaves the theme's markup, templates and forms unchanged.
The widget's automated repairs depend on guessing what an image shows, what a button does and what an unlabelled field asks for. W3C states that evaluation tools cannot determine accessibility and that human judgement is required. Automated repair has the same limit. The widget also becomes part of the page and has to be keyboard-operable and correctly named itself.
The fix belongs in the theme, the page-builder settings and the content.
Testing: automated tools catch about a third of issues
Automated scanners such as axe, WAVE and Lighthouse test only the checks a machine can decide. W3C's guidance is direct: evaluation tools cannot determine accessibility, they can only assist, and human judgement is required. A clean scan is evidence that the scanned rules passed on that page, and nothing more.
The proportion is measured: the UK Government Digital Service's 2017 audit ran thirteen tools against a page with 142 known barriers and the best found 30 to 40 percent of them; the GOV.UK Design System still cites "only about 30% of issues" as the reason it does not rely on automated testing alone.
The manual pass has four parts: a keyboard-only walk through each template, covering tab order, focus, menus, modals and forms; a screen-reader pass with NVDA or VoiceOver on navigation, forms and checkout; a zoom to 200%; and a deliberate trigger of every form error. A WordPress site is a small number of templates repeated, so findings are recorded per template.
Elementor and page-builder specific pitfalls
Page builders let an editor choose any heading tag, colour and widget on any page, so accessibility depends on every editing decision and not only on the theme. The recurring problems are heading tags picked for size, icon and image widgets without accessible names, popups that trap or lose keyboard focus, and motion that cannot be paused.
In Elementor these have known locations. The Heading widget has an HTML tag setting that is independent of visual size. Global colours can fail contrast across the whole site, and can also fix it in one edit. Form widgets allow labels to be hidden, leaving only placeholders. Carousels and animated sections that start automatically need a pause control. Popups need focus moved in on open and returned on close.
Remediation vs rebuild
Remediation fits when failures sit in a few shared templates, global styles and form settings, because one fix repeats across the site. A rebuild is warranted when the theme's markup cannot be edited, is no longer maintained, or fails structurally in navigation and forms. The evidence decides, template by template, and the two options are costed separately.
A Health Report records each failure with its criterion and where the fix lives: global style, theme file, plugin setting or content. WP Doctor documents findings against WCAG. It does not certify conformance, and whether an organization meets the AODA is a legal conclusion for counsel. The same forms carry consent obligations under CASL. Other regimes are indexed on the compliance hub.
---
Every one of these is checked in a Health Report
A paid, fixed-scope diagnosis of your WordPress site — technical, performance, security and Canadian compliance — delivered as a written report you own.
Book a Health Report Back to the compliance hub