If you run a nonprofit in Ontario, AODA applies to you. If you have one or more employees and you provide goods, services, or facilities to the public, you are covered. The 2025 deadline for WCAG 2.0 Level AA compliance on websites has come and gone. Enforcement is real. Fines are real.
We get calls about this every few weeks. Usually it's a nonprofit that just got asked about AODA in a funder application, or a board member who saw a news article about a fine and is suddenly nervous. Almost always, the next sentence is some version of, can we just install one of those accessibility overlay widgets and be done with it?
The short answer is no. The longer answer is what this post is for.
Here is what AODA actually requires for your website in 2026, what most organizations get wrong, and a real checklist you can work through.
What AODA actually is
The Accessibility for Ontarians with Disabilities Act became law in 2005. The goal was to make Ontario accessible by 2025. Different parts of the law phased in over the years. The piece most nonprofits care about, the Information and Communications Standards, requires that public-facing websites and web content meet WCAG 2.0 Level AA.
That deadline was January 1, 2021 for most organizations. If your nonprofit has 50 or more employees, or you're a public sector organization, you've also been subject to accessibility reporting requirements for years.
The piece that catches a lot of nonprofits off guard is that AODA is enforced. The Accessibility Directorate of Ontario conducts audits. Fines can hit $50,000 per day for individuals and up to $100,000 per day for corporations. Most enforcement we've seen targets larger organizations, but the law applies to small ones too.
Why accessibility overlays are not a fix
An accessibility overlay is a JavaScript widget you drop onto your site that claims to make it WCAG compliant. You've probably seen them. A little blue or orange icon in the corner that opens a panel with toggles for contrast, font size, screen reader mode, and so on.
These tools have a marketing problem and a substance problem.
The marketing problem is that they tell you they make your site compliant. They do not. The accessibility community is very clear on this. The W3C, the organization that writes WCAG, has stated that overlays do not meet WCAG requirements on their own. Over 800 accessibility professionals have signed the overlay fact sheet at overlayfactsheet.com saying the same.
The substance problem is that they often make sites worse for users who rely on assistive technology. Screen readers conflict with the overlay's own interface. Users get trapped in modals. Keyboard navigation breaks. We have personally seen overlays cause AODA complaints rather than prevent them.
One more thing. Overlays do not protect you legally. There have been multiple lawsuits in the US where companies installed overlays and got sued anyway, because the underlying site still didn't meet WCAG. Ontario courts have not yet ruled definitively on overlay tools under AODA, but there is no reason to expect a different outcome here.
If a vendor tells you a single widget will make your site AODA compliant, that vendor is selling you something that does not exist.
The actual AODA compliance checklist
This is the work. There is no shortcut. The good news is that most of it is one-time effort, and once your site is built right, ongoing maintenance is light.
1. Text alternatives for non-text content
Every image on your site needs alt text that describes what the image is or what it does. Decorative images get empty alt text. Logos get the organization name. Photos of events get a short description of what is shown. Icons that act as buttons get alt text describing the action, not the icon.
Where nonprofits usually fail: donor logos in the footer with no alt text, photo galleries with generic alt like image1.jpg, infographics with no text alternative for the data.
2. Captions and transcripts for media
Pre-recorded video needs captions. Pre-recorded audio needs a transcript. If you embed YouTube videos, you must turn on captions and verify they are accurate, not auto-generated nonsense.
Where nonprofits usually fail: client testimonial videos with no captions, annual report videos that talk over background music with no transcript, webinar recordings posted without any text alternative.
3. Color contrast
Text on your site has to have enough contrast against its background. WCAG 2.0 AA requires 4.5:1 for normal text, 3:1 for large text. Light gray text on a white background is the most common failure we see.
Where nonprofits usually fail: light gray body text used to look minimalist, brand colors used for buttons that do not meet contrast on their background, text overlaid on photos without enough contrast.
4. Keyboard navigation
Every interactive element on your site has to be reachable and usable with a keyboard alone. No mouse. Tab through your homepage right now. Can you reach every link, every button, every form field? Can you see where the focus is? Can you escape out of menus that open?
Where nonprofits usually fail: custom dropdown menus that only respond to mouse hover, modal pop-ups that trap keyboard focus, hamburger menus on mobile that cannot be closed with the keyboard.
5. Forms that actually work
Every form field needs a visible label. Required fields need to be marked in a way that does not rely on color alone. Error messages need to be clear and announced to screen readers. Form submissions need a confirmation that screen readers can detect.
Where nonprofits usually fail: donation forms with placeholder text instead of labels, contact forms that only show errors as red borders, multi-step forms that do not announce step changes.
6. Page structure and headings
Pages need a proper heading hierarchy. One H1 per page. H2s for major sections. H3s nested under H2s. Skipping levels confuses screen readers and breaks the document outline.
Where nonprofits usually fail: H1s used for visual styling, multiple H1s per page, headings chosen for size rather than meaning.
7. Link text that makes sense out of context
Avoid links that just say click here or read more. Screen reader users often pull up a list of all links on a page. If half of them say click here, that list is useless.
Where nonprofits usually fail: blog index pages where every read more link is identical, footer links with redundant text, calls to action that lose meaning when read alone.
8. Documents and PDFs
PDFs you link to from your site also need to be accessible. Tagged structure, alt text for images, real text instead of scanned images, logical reading order. Annual reports and grant filings are the worst offenders here.
Where nonprofits usually fail: scanned PDFs of historical documents with no OCR, annual reports designed in InDesign and exported without accessibility tags, government forms reposted without remediation.
9. Compatible with assistive technology
Your site needs to work with screen readers, screen magnifiers, voice control software, and other assistive tools. This is the bucket that catches everything from ARIA labels to focus management to dynamic content updates.
Where nonprofits usually fail: custom-built navigation that lacks ARIA roles, single-page apps where route changes are not announced, carousels and sliders that screen readers cannot navigate.
10. An accessibility statement
AODA requires you to have an accessibility policy and to make it publicly available. A short page on your site stating your commitment, the standard you aim to meet, and how to contact you if someone runs into a barrier. This is required and it is one of the easiest items on the list.
Where nonprofits usually fail: no accessibility page at all, page exists but is buried in the footer with no clear contact path, statement copied from another organization without being adapted.
How to actually audit your site
You cannot test for AODA compliance with a single tool. You need a combination of automated scanning and manual testing.
Automated tools like axe DevTools, WAVE, or Lighthouse will catch maybe 30 to 40 percent of issues. They are great for finding missing alt text, color contrast failures, and structural problems. They cannot tell you whether your alt text actually describes the image, whether your keyboard navigation makes sense, whether your forms are usable in practice.
The other 60 percent is manual. Tab through every page. Use a screen reader like NVDA on Windows or VoiceOver on Mac for at least one full session on your site. Have someone who actually uses assistive technology review the site if you can.
If you do not have anyone in-house who can do this work, hire someone who can. Most nonprofits underestimate the complexity here and overestimate what their existing web vendor can deliver.
When to hire help
The honest answer: most nonprofits should hire help for the initial audit and remediation, then handle ongoing maintenance in-house once your team is trained.
A proper AODA audit on a typical nonprofit site is two to five days of work. Remediation depends on what we find. A site built in the last few years on a modern platform might need a week or two of fixes. A site that has not been touched since 2018 might need a full rebuild.
That is also where Pragmatica comes in. We have built and audited accessible sites for Canadian nonprofits, healthcare organizations, and public sector clients for over 20 years. WCAG 2.1 AA is the standard baseline on every site we build. Manual accessibility audits are part of the process, not an add-on.
If you want to know where your site actually stands, see what our accessibility services cover or get in touch and we will take a look.
