The actual checklist for testing an Ontario website against WCAG 2.0 AA — what to check, how to test each item yourself, and how to turn the results into something you can stand behind.
- An AODA website audit checklist and Ontario’s own Accessibility Standards Checklist are different tools — the government’s covers policy and training under the IASR; this one covers whether your website itself passes WCAG 2.0 Level AA.
- You don’t need to test every page. The W3C’s own evaluation methodology calls for a representative sample — homepage, key templates, and any page with a form — not a page-by-page crawl of the whole site.
- Ten checks catch the large majority of real-world WCAG 2.0 AA failures: alt text, contrast, keyboard/focus, form labels, link and button names, heading structure, ARIA, captions, 200% text resize, and form error messages.
- Automated scanners (Lighthouse, axe, WAVE) are a fast, useful first pass. The W3C’s own guidance is blunt about their ceiling: no tool alone can determine if a site meets accessibility standards — a human still has to test it.
- Testing with a real screen reader matters more than picking the trendiest one — JAWS and NVDA together cover roughly three-quarters of desktop screen reader users, per WebAIM’s most recent survey.
What actually belongs on an AODA audit checklist?
Two different things get called “the AODA checklist,” and they answer different questions. Ontario publishes its own Accessibility Standards Checklist, a worksheet covering the full Integrated Accessibility Standards Regulation — customer service, staff training, information and communications, and employment accommodation. It’s a genuinely useful first pass for the policy side of AODA. It does not test a single line of your website’s code.
This checklist is the other half: what to actually check on your website so it conforms to WCAG 2.0 Level AA, the specific technical standard Ontario’s regulation names for organizations with 50 or more employees. If you haven’t nailed down whether that duty even applies to your business yet, that’s covered in the employee threshold breakdown and the wider legal picture in the AODA website compliance guide. This piece assumes you already know you need to test the site, and gets straight into how.
How do you actually run an AODA website audit, step by step?
Scope it, sample it, scan it, then test it by hand — in that order, because skipping straight to a scanner is how most of the real issues get missed.
- Define the scope. List every unique template on your site: homepage, category or listing pages, a standard article or product page, your contact or quote form, checkout if you sell online.
- Pick a representative sample. One or two real pages per template, not every page on the site.
- Run an automated scan — Lighthouse, axe, or WAVE — on each sampled page to catch the obvious stuff fast: missing alt attributes, contrast failures, some structural issues.
- Do a manual keyboard-only pass. Unplug the mouse and Tab through every sampled page, every menu, every form.
- Spot-check with a screen reader on the flows that matter most — navigation, your main form, checkout if you have one.
- Check contrast and heading order by hand against every distinct text and background colour pairing you found.
- Write a prioritized fix list ranked by real user impact, fix it in code, then retest the same pages before you call it done.
None of this needs to happen in a single sitting. What it does need is a human actually doing steps 4 and 5 — the W3C’s own guidance on this is direct: no tool alone can determine if a site meets accessibility standards, and knowledgeable human evaluation is required.
How many pages do you actually need to test?
Not every page — a representative sample built around your site’s unique templates, not its total page count. Testing a 40-page brochure site built on four templates and testing a 4,000-page e-commerce catalogue built on the same four templates takes roughly the same amount of work, because the template is what determines whether a given pattern passes or fails, not how many pages use it.
The W3C’s Website Accessibility Conformance Evaluation Methodology (WCAG-EM) lays out the formal version of this: define your evaluation scope, explore the site to understand its structure, select a representative sample of pages, evaluate that sample, then report the findings. For a typical Ontario business site, a practical sample usually includes the homepage, one page per distinct template or layout, any page with a form, your highest-traffic content page, and anything embedding a PDF or a third-party widget, since those often fail in ways the rest of the site doesn’t.
The AODA website audit checklist: what to test, and how
Ten checks, each one with a way to test it yourself before you ever open a scanner.
| What to check | Test it yourself | Typical fix |
|---|---|---|
| Alt text on images | Turn off images in your browser — does the page still make sense? | Write specific alt text describing purpose; leave decorative images with an empty alt attribute |
| Colour contrast | Run a contrast checker against your two most common text/background pairings | Adjust to 4.5:1 for normal text, 3:1 for large text, at the design-token level |
| Keyboard navigation and focus | Unplug the mouse; Tab through the whole page — can you reach and use everything? | Fix tab order, restore a visible focus outline, remove any keyboard traps |
| Form labels | Click each visible form label — does focus jump to its matching field? | Pair every input with a real, coded <label> or an aria-label |
| Link and button names | List every link on a page — how many just say “click here”? | Rewrite link and button text to describe the destination or action |
| Heading structure | List only the page’s headings — does it read like a real table of contents? | Reorder headings into one logical H1-then-H2-then-H3 sequence |
| ARIA usage | Does every element with a role like “button” actually respond to Enter or Space? | Remove ARIA that isn’t backed by real behaviour; prefer native HTML elements |
| Captions and transcripts | Play a video on mute — is anything meaningful lost? | Add accurate synced captions; human-edit anything auto-generated |
| Text resize / reflow | Zoom your browser to 200% — does content overlap, clip, or disappear? | Use relative units (rem, %, em) instead of fixed pixel widths and heights |
| Form error messages | Submit a form with one field wrong — does the error name the field and the problem? | Pair a specific, visible message with the invalid field, not just a red border |
Run this against your sampled pages from the previous section and you’ve covered the failures that account for the large majority of real-world WCAG 2.0 AA gaps.
What tools do you need, and what can’t a tool catch?
Automated scanners — Lighthouse, axe, and WAVE are the three worth running — catch missing alt attributes, obvious contrast failures, and some structural issues in seconds. What none of them can catch: whether your link text actually makes sense in context, whether a keyboard user gets trapped inside your mega-menu, or whether a screen reader user can actually complete your contact form. That gap is exactly why manual testing isn’t optional, a point covered in more depth in the WCAG 2.0 AA explainer.
For the screen reader pass, don’t overthink which one to pick. Per WebAIM’s most recent Screen Reader User Survey, JAWS and NVDA together account for roughly three-quarters of desktop screen reader use, with VoiceOver close behind at around 10%; on mobile, VoiceOver dominates at over 70%. NVDA is free and pairs well with Chrome or Firefox, which makes it the practical starting point for a first audit — you don’t need every screen reader on the market, just one you actually test with rather than none.
One thing worth naming directly: an accessibility overlay or plugin does none of the above. It runs after your page has already rendered and can’t rewrite the underlying markup this checklist tests against — the full reasoning is in why an overlay doesn’t make you compliant.
How do you turn audit findings into evidence for your compliance report?
Write down what you tested, when, and what you found — a fix log, not just a memory of having done the work. If you’re at 50+ employees, that log is what actually backs up the website question on your December 31, 2026 accessibility compliance report, covered in full in the deadline explainer.
A usable record needs four things: the date you tested, the pages and templates sampled, the method used (automated scan plus which manual checks), and a list of what you found with each item marked open or fixed. That log is also exactly what you’d want in hand if a director ever followed up on your report — the honest difference between attesting to something you tested and attesting to something you assumed, a gap covered in more detail in the AODA website compliance guide.
Should you run this audit yourself, or hire someone?
A small brochure site with a handful of templates is genuinely doable in-house if someone’s willing to unplug the mouse and actually work through the checklist above. A larger site, an e-commerce catalogue, or anything built on a heavy page builder like Divi, Elementor, or WPBakery is a different proposition — those tools generate div-based buttons and sliders that a checklist can flag but that need real development work to fix, not a settings toggle. The AODA and WordPress guide goes deep on exactly where those builders fail by default.
If you’d rather have someone run this audit and fix what it finds, that’s what jbe.works Accessibility does — a free scan is an automated pass plus a manual keyboard-and-screen-reader spot check of your key pages, back to you within a few days as a plain-English punch list. Get in touch and I’ll tell you honestly where your site stands.
What should you do with this checklist next?
Scope your sample, run the ten checks above against it, and write down what you find as you go — that log is worth more than the audit itself once your report is due. If you’re not yet sure whether the WCAG duty even applies to your business, settle that first in the employee threshold guide, and for the full picture of what “compliant” means beyond just the website, see the AODA website compliance guide.
And if the honest answer is that your site probably wouldn’t survive this checklist, that’s exactly what jbe.works Accessibility exists to fix — properly, in code, before December 31, 2026 gets closer than it already is.
Frequently asked questions
Quick answers to what comes up most when Ontario businesses start their first AODA website audit.
Need the site to pass WCAG 2.0 AA before the December 31, 2026 AODA deadline?
Audit, remediation and the compliance report, handled end to end for Ontario businesses.
AODA & WCAG Accessibility Compliance →Is your site costing you customers?
Enter your website and get a free 60-second performance, SEO & accessibility report.
~60 seconds · No login