What is AODA, and what does it require?
The Accessibility for Ontarians with Disabilities Act (AODA) is provincial legislation passed in 2005, with the goal of making Ontario fully accessible by 2025. Under the Integrated Accessibility Standards Regulation (IASR), public-sector organizations and private businesses with 50 or more Ontario employees must ensure their public-facing websites conform to the Web Content Accessibility Guidelines (WCAG) 2.0 Level AA.
WCAG is structured around four guiding principles — the report above breaks your score down against each one. Together they cover everything from alt text and color contrast to keyboard navigation, form labelling, and assistive-technology compatibility.
The four WCAG principles, explained
Perceivable
Every user can perceive the content with at least one of their senses. Alt text for images, captions for video, sufficient color contrast, and structure that works without sight.
Operable
Every user can operate the interface. Keyboard-only navigation, no time-out traps, no flashing content that could trigger seizures, clear focus indicators.
Understandable
The content and behavior are predictable. Page language is declared. Form errors are explained. Inputs are labelled. Navigation works the same way across the site.
Robust
Compatibility with assistive technology — current and future. Valid HTML, unique IDs, proper ARIA usage, no nameless buttons or iframes.
The most common AODA violations
Across the Ontario websites we've audited, the same handful of issues come up over and over. None of them are hard to fix — they just require someone to look.
- Images without alt text. Decorative images need an empty alt (alt=""), content images need a real description. The phrase "image" or a filename is never acceptable alt text.
- Form fields without labels. Every input needs a
<label for="">or an aria-label. Placeholder text alone is not a label — it disappears when the user starts typing. - Low color contrast. Normal text needs a 4.5:1 ratio against its background. Light grey on white is the most common offender — easy to spot, easy to fix.
- Generic link text. "Click here" and "Read more" out of context tell screen-reader users nothing. Rewrite the link text so it makes sense alone.
- Missing page structure. No
<main>landmark, no skip-to-content link, multiple<h1>elements, or headings used for styling alone. Structure is how assistive tech navigates. - Iframes without titles. Every embedded YouTube video, Google Map, scheduling widget, or chat needs a title attribute describing what's inside.
What does an AODA-compliant website look like in practice?
In day-to-day terms: a person using only a keyboard can navigate every page; a person using a screen reader hears a coherent, structured description of each page; a person with low vision can zoom in 200% without losing functionality; a person with colorblindness can distinguish every interactive element. None of this requires a separate "accessible version" of your site — it requires a well-built single version that works for everyone.
Compliance is also a process, not a one-time fix. New content, new templates, and third-party widgets can all introduce regressions. The goal is to bake accessibility into your design and development workflow, not bolt it on at the end.
How automated scanning fits into a real audit
The scan above catches what software can reliably catch — about 30 to 50 percent of WCAG issues, depending on the page. A complete AODA audit also includes:
- Manual keyboard testing. Every interactive element must be reachable and operable using only the keyboard, with a visible focus indicator throughout.
- Screen-reader walkthroughs. A real user tests with NVDA, JAWS, or VoiceOver to confirm the content makes sense when read aloud and that interactive widgets announce their state correctly.
- Live color contrast measurement. Across every state, hover, focus, and viewport — not just the inline styles a scanner can see.
- Multi-template coverage. Scanning one home page isn't enough. A full audit samples each template type — product listing, article, contact form, checkout — to find systemic issues.
- Accessibility statement and process. A documented plan, a way for users to report barriers, and a workflow to fix them.
Frequently asked questions
What is AODA compliance?
AODA stands for the Accessibility for Ontarians with Disabilities Act. Under the Integrated Accessibility Standards Regulation, businesses and organizations with 50 or more employees, as well as public-sector bodies, must conform to WCAG 2.0 Level AA for their public websites. Smaller businesses are not legally bound by the same deadline, but the same standards are recommended.
Who needs to comply with AODA?
Private and not-for-profit organizations with 50 or more Ontario employees, plus all designated public-sector organizations, must meet WCAG 2.0 Level AA on public-facing websites. Smaller private businesses aren't yet bound by the WCAG requirement but are subject to AODA's general customer-service and information-and-communications standards.
What are the penalties for non-compliance?
Individuals can be fined up to $50,000 per day of non-compliance, and corporations up to $100,000 per day. In practice, the Ontario Ministry sends warnings and compliance orders before levying fines, but the legal exposure is real — and accessibility complaints under the Ontario Human Rights Code carry separate liability on top.
Is this scan a substitute for a full audit?
No — this is an automated static scan. We check the page's HTML against around two-dozen WCAG 2.0 Level AA criteria that can be assessed without executing JavaScript or rendering the page. A complete AODA audit also requires manual testing with assistive technologies (screen readers, keyboard-only navigation), checks across multiple page templates, and contrast measurement of all on-page colors. Automated tools typically catch 30-50% of WCAG issues.
Why was my page so easy or hard to scan?
Single-page applications (SPAs) that render content with JavaScript will look mostly empty to our scanner — we see only the initial HTML the server sends. Pages with server-side rendering (Next.js, Astro, WordPress, Webflow, plain HTML) give us the complete document to analyze. If your score looks suspiciously high or low, that's often the reason.
What WCAG level does AODA require?
AODA's IASR regulation references WCAG 2.0 Level AA. WCAG 2.1 and 2.2 are newer versions with additional success criteria, but Ontario law currently mandates Level AA conformance to 2.0. Many organizations target 2.1 AA voluntarily because it covers mobile and cognitive accessibility better.
Do I need an accessibility statement on my site?
AODA requires designated public-sector organizations to publish a multi-year accessibility plan. While private businesses aren't required to publish a public statement, doing so is a strong best practice — it shows good faith, gives users a way to report issues, and reduces the risk of complaints.
How often should I re-scan my website?
Run an automated scan after every major release, content overhaul, or design refresh. For sites that publish content daily (news, blogs, e-commerce), a monthly automated scan plus a full manual audit annually is a reasonable cadence.
Does AODA apply to PDFs, videos, and third-party tools?
Yes. AODA applies to public content under your organization's control, including PDFs, videos, and embedded third-party widgets (forms, chat, scheduling). PDFs must be accessible (tagged, with alt text and reading order), videos must have captions, and embedded tools should meet the same WCAG criteria — or you should offer an accessible alternative.