What AODA requires of a website
One sentence covers it: public facing websites and web content must conform to the Web Content Accessibility Guidelines, version 2.0, Level AA. The requirement applies to content created or significantly refreshed after 1 January 2012, which in practice means your current site.
Two things make this different from most compliance work. There is no audit you book and pass, so nobody will tell you that you are finished. And the standard is technical rather than procedural, so it cannot be satisfied by writing a policy. Either a keyboard user can complete your contact form or they cannot.
It is worth separating the two obligations that get confused with each other. The technical obligation is to meet WCAG 2.0 AA. The administrative obligation is to file an accessibility compliance report on a three year cycle, which is covered in the AODA compliance report. Filing the report does not make your site accessible, and an accessible site does not excuse a missed filing.
Who it applies to
The website requirement attaches at 50 or more employees. Below that, an organisation still has AODA duties, including an accessibility policy, staff training and providing accessible formats on request, but the WCAG conformance requirement is not among them.
- 50 or more employees: public facing websites and web content must meet WCAG 2.0 Level AA
- 20 or more employees: an accessibility compliance report must be filed every three years
- 1 to 49 employees: policy, training and accessible formats on request still apply
- Public sector organisations sit under a stricter and separate set of obligations
Count employees in Ontario, and count people rather than full time equivalents. A business that runs on part time staff can pass the threshold without feeling any larger, which is how most organisations discover they were already in scope.
WCAG 2.0 AA in plain terms
WCAG is organised under four principles. Stripped of the formal language, they ask four questions about your site.
| Principle | The question it asks |
|---|---|
| Perceivable | Can someone receive the content if they cannot see or hear it? |
| Operable | Can someone use it without a mouse? |
| Understandable | Is it predictable, and does it explain its own errors? |
| Robust | Can assistive technology interpret the markup correctly? |
Level AA is the middle of three conformance levels and is the one legislation generally references. The practical content of AA, for an ordinary business website, is a fairly short list: text alternatives, keyboard operability, sufficient colour contrast, labelled form fields, visible focus, sensible heading structure, captions on video, and no content that depends on colour alone to make sense.
A note on versions. AODA is written against WCAG 2.0. WCAG 2.1 AA is newer and is referenced by several other regimes, including the standard the federal accessibility regulations point at. If you are paying for this work once, build to 2.1 AA. It covers 2.0 and leaves you in a better position if your obligations widen.
The eight things that fail most
Across ordinary business websites the same failures recur. None of them are exotic and most are cheap to fix once somebody looks.
- Images without text alternatives. Decorative images need an empty alt attribute, meaningful ones need a description, and an image of text needs the text.
- Low contrast text. Light grey body copy on white is the most common single failure on modern sites, and it usually comes from the theme rather than the content.
- Form fields without labels. A placeholder is not a label. It disappears on focus and screen readers treat it differently.
- Keyboard traps and invisible focus. Open a menu, press Tab, and see whether you can tell where you are and get out again.
- Headings used for size. An h3 chosen because it looked right breaks the outline that screen reader users navigate by.
- Link text that says nothing. A page of links all reading "read more" is useless out of context, and out of context is how they are often heard.
- Video without captions. Auto generated captions are a starting point, not a deliverable.
- Error messages that only use colour. A red border with no text does not tell a colour blind user what went wrong.
If you fix only the first four you will have dealt with the majority of the real barriers on a typical site. Items two and three are also the ones most likely to be systematic, which means a single change to the theme or the form template fixes them everywhere at once.
How to test your own site honestly
Automated tools find the mechanical failures: missing alt attributes, contrast ratios, absent labels, duplicate IDs. They cannot judge whether your alt text is accurate, whether your heading structure makes sense, or whether a keyboard user can actually finish a booking. A clean automated scan is not a pass, and anybody selling you one as a certificate is selling you something else.
Do these four in order. The first takes minutes, the last takes an afternoon, and together they will tell you where you stand.
- Run an automated scan on your top ten pages, not just the homepage. Fix what it finds, because it is the cheap half.
- Unplug the mouse. Navigate the site by Tab, Shift+Tab, Enter and the arrow keys. Reach the main navigation, open the menu, complete the contact form, close any pop up. Note every point where you cannot see where you are or cannot proceed.
- Turn on a screen reader and listen to one page end to end. VoiceOver on macOS and NVDA on Windows are both free. You are listening for whether the page makes sense in order, and whether links and buttons announce what they do.
- Zoom to 200 per cent and look for content that disappears, overlaps or requires sideways scrolling.
Step two is the single most informative thing most site owners ever do. It is uncomfortable, it takes ten minutes, and it usually finds a blocker on the page that matters most commercially.
WordPress specifics
Most accessibility problems on a WordPress site come from three places, in this order: the theme, the page builder, and the plugins that output front end markup.
| Source | Typical problem | What fixes it |
|---|---|---|
| Theme | Contrast, focus styles, heading levels baked into templates | Child theme overrides, or a theme change if it is deep |
| Page builder | Div soup, headings chosen by size, custom widgets with no keyboard support | Rebuild the affected sections with accessible patterns |
| Forms plugin | Placeholder instead of label, errors shown by colour only | Template overrides, or a plugin that does it properly |
| Sliders and modals | Keyboard traps, no visible focus, auto advancing content | Usually replace, rarely repair |
| Content | Missing alt text, link text that says nothing | An editorial standard plus training, not code |
The last row is the one people forget to plan for. You can fix every template and be back where you started in a year, because accessibility is partly an editorial practice. Decide who writes alt text, give them a one page standard, and check it as part of publishing. A site that stays accessible needs that more than it needs a one off audit, which is part of what ongoing maintenance and support is for.
One thing worth knowing before you commission work: fixing accessibility often improves other things you are already paying attention to. Proper heading structure, descriptive link text and real labels are also what search engines read, and lighter, better structured markup tends to load faster. It is unusual for compliance work to pay for itself twice, and this is one of those cases.
Why overlay widgets are not a fix
You will be offered a script that promises compliance for a monthly fee. It adds a floating accessibility button with contrast and font size controls, and sometimes claims to repair the page automatically.
They do not work for the purpose they are sold for, for a simple reason: the problems are in your markup and an overlay sits on top of it. A script cannot know what your unlabelled image is of, cannot decide what your button should be called, and cannot make a keyboard trap passable. Users of assistive technology generally report that overlays interfere with the tools they already use well.
- They do not change your legal obligation
- They cannot supply missing text alternatives or labels
- They can conflict with a user's own screen reader or browser settings
- They create an impression of compliance that delays the real work
If a widget is already on your site, leaving it in place while you fix the underlying issues is a decision you can make. Treating it as the fix is not.
A realistic plan
- Confirm your employee count and which AODA obligations apply to you
- Run an automated scan across your ten most visited pages
- Do the keyboard test on the homepage, your main service page and your contact form
- Fix the systematic issues first: contrast, focus styles, form labels
- Fix the content issues next, and write the one page editorial standard while you do
- Retest by keyboard and with a screen reader, because the scan will not confirm these
- Add accessibility to your publishing checklist so it does not regress
- Keep a record of what you tested, when, and what you fixed
Step eight matters more than it looks. WCAG conformance is not a certificate, so what you can show is the work: what was tested, what was found, what was repaired and when. That record is also what makes your next compliance report straightforward rather than a guess.
If the keyboard test found a blocker on a page that earns you money, that is the place to start and it is usually a contained piece of work. We fix accessibility issues on WordPress sites, from theme level contrast and focus problems to rebuilding a form or a menu that cannot be operated without a mouse. Send us your URL and we will tell you what we find and what it would take, before you commit to anything.