Your AODA Compliance Checklist for 2026

If you're looking at your website, your latest accessibility report, or a government compliance task and wondering where to start, that's a normal place to be. Most Ontario organizations don't struggle because AODA is impossible. They struggle because accessibility gets treated like a single remediation sprint when the law and the work both require an ongoing process.

A practical AODA compliance checklist helps you turn that complexity into repeatable work. You identify what applies to your organization, fix priority barriers, document decisions, establish ownership, and keep the site compliant as content, features, and vendors change.

AODA Compliance Quick Summary

AODA exists to make services, including digital services, accessible to people with disabilities in Ontario. For websites, the simplest way to think about compliance is this. Know your threshold, meet the web standard that applies, and treat reporting and governance as part of the job, not admin work around it.

For busy teams, these are the points that matter most:

• If your organization has 50 or more employees: your web accessibility obligations include WCAG 2.0 Level AA requirements under AODA, as outlined by AODA compliance guidance.
• If you're a private organization or nonprofit with 20 or more employees: you must file an accessibility compliance report every three years, based on Ontario AODA obligations referenced by the same legal framework.
• If you're a designated public-sector organization: accessibility reporting happens every two years under the same Ontario structure.
• If your organization has 50 or more employees: accessibility work also extends beyond web fixes into documented planning and governance.
• If your site changes often: your checklist can't stop at launch. New pages, forms, PDFs, videos, and integrations can all introduce fresh barriers.

Executive takeaway: A strong AODA compliance checklist isn't just a list of WCAG fixes. It's a working system for planning, testing, remediating, documenting, and reporting.

Why AODA Compliance Matters Now More Than Ever

A common scenario looks like this. A business owner in Ontario approves a redesign, launches new landing pages, adds online forms, and starts publishing more video content. Then someone from operations, legal, procurement, or HR asks a basic question: are we compliant with AODA?

That question usually lands late. By then, the site is already live, vendors are involved, and no one is sure whether accessibility means fixing a few pages or rebuilding a process. In practice, it's both. Some issues are technical, but the reason they matter is larger than code.

AODA was created in response to a real access need in the province. Approximately 2.9 million Ontarians have one or more disabilities, according to Recite Me's overview of the AODA website compliance checklist. That changes the conversation. You're not serving a narrow edge case. You're serving a substantial part of the population.

Accessibility affects everyday business decisions

When teams approach accessibility early, they usually make better decisions across the board. Navigation gets clearer. Forms get easier to complete. Content becomes easier to understand. Videos become usable in more situations. Internal QA also improves because teams start testing complete user journeys instead of isolated pages.

That matters for sales, service, hiring, support, and reputation. It also matters operationally. Once accessibility is on your regulatory list, missed ownership becomes expensive in time and rework, even when the original issue seemed minor.

Accessibility work goes smoother when leadership stops asking, "How do we pass?" and starts asking, "How do we keep this usable as the site evolves?"

The shift most organizations need

The biggest mindset change is moving from reactive fixes to managed accessibility. AODA pushed web accessibility out of the realm of optional best practice and into enforceable business responsibility. For Ontario organizations, that means your website is no longer separate from compliance operations. It's part of them.

Does Your Organization Need to Comply With AODA

This is the first question to settle, and it needs a clean answer. Under Ontario's Accessibility for Ontarians with Disabilities Act, web accessibility obligations depend on your organization type and employee count. The rules aren't identical for every business, nonprofit, and public-sector entity.

The clearest summary is this. Organizations with 50 or more employees must meet WCAG 2.0 Level AA requirements, while private organizations and nonprofits with 20 or more employees must file an accessibility compliance report every three years. Designated public-sector organizations must file every two years, as described in AudioEye's AODA compliance overview.

AODA web compliance requirements by organization

Organization Type & Size	Web Content Standard	Compliance Reporting Frequency
Private organization or nonprofit with fewer than 20 employees	Obligations can still exist under broader accessibility expectations, but the verified reporting threshold listed here starts at 20 employees	Not specified here
Private organization or nonprofit with 20 or more employees	Reporting duty applies under AODA	Every three years
Organization with 50 or more employees	WCAG 2.0 Level AA required	Reporting obligations depend on sector
Designated public-sector organization	Sector-specific accessibility obligations apply	Every two years

How to interpret the table correctly

The mistake I see most often is assuming one threshold answers everything. It doesn't. Reporting duties and web standards don't always sit under the same headcount trigger, so teams need to check both.

Use this quick interpretation:

• If you're under the reporting threshold: don't assume accessibility is irrelevant. It still affects usability, procurement, and risk.
• If you've crossed the reporting threshold: assign ownership for filings early. Don't leave it with marketing by accident.
• If you've crossed the WCAG threshold: your website, templates, forms, media, and publishing workflow need structured review.
• If you're unsure how Ontario defines your organization: confirm sector classification before building your checklist.

For many teams, this is also the point where they need plain-language legal context. WebAbility's AODA insights are useful for aligning internal stakeholders around what AODA means in practice.

What this means for business owners

If you're an owner or operator, your main job isn't memorizing legal language. It's making sure someone owns each requirement. One person should own reporting. One team should own web remediation. Someone should approve policy, training, and publishing standards. If no one owns those pieces, compliance work stalls fast.

The Core AODA Web Accessibility Checklist

A useful AODA compliance checklist shouldn't read like a pile of abstract success criteria. It should help your team inspect the site the way users experience it. The cleanest way to do that is to organize the work around the four accessibility principles commonly known as POUR: perceivable, operable, understandable, and adaptable.

Start with this visual summary, then use the practical checks below to review your own site.

Perceivable

Users must be able to perceive the information on the page. If content depends on sight, hearing, or color alone, some visitors won't get it.

Check these items first:

• Text alternatives for images: Product images, icons, charts, and banners need alt text that communicates purpose, not just appearance.
• Captions and transcripts for media: Video content should include captions, and audio content should have a text alternative where appropriate.
• Clear structure: Headings should reflect the page hierarchy so assistive technologies can interpret the content properly.
• Contrast and visual clarity: Text and interface elements need enough visual distinction from surrounding colors.

A common failure here is decorative thinking. Teams spend time polishing hero sections while leaving core product images, buttons, or charts without useful text alternatives. That creates a polished page that's still inaccessible.

Operable

Users must be able to operate the interface. For many people, that means using a keyboard, not a mouse.

The technical controls most closely associated with AODA checklist work include keyboard-only operability, visible focus indicators, meaningful headings and labels, error messages that identify both the issue and correction steps, and compatibility with assistive technologies, as explained in AudioEye's AODA compliance checklist article.

Use that principle on real journeys, not isolated components:

• Keyboard navigation: Can a user reach menus, popups, forms, filters, and buttons using only the keyboard?
• Visible focus: When tabbing through the page, is it always obvious where the user is?
• No keyboard traps: Can a user move into and out of menus, dialogs, and embedded tools without getting stuck?
• Consistent navigation: Do repeated elements behave the same way across templates?

Practical rule: Unplug the mouse and complete your highest-value tasks. If a customer can't search, submit a form, book, buy, or log in by keyboard alone, your checklist isn't complete.

For teams that need a more detailed interpretation of the web standard itself, it is beneficial to understand AODA digital standards.

A short walkthrough can help your team align on what to test:

Understandable

Users must be able to understand both the content and the interactions. Many compliant-looking sites often fail on this front.

Review:

• Form labels: Every field needs a clear, meaningful label.
• Helpful instructions: If a field has a required format, tell the user before submission.
• Useful error messages: Error text should identify the issue and explain how to correct it.
• Predictable behavior: Buttons, links, and controls should act consistently.

This is especially important on lead forms, account registration, service requests, and checkout steps. If your form says only "invalid input," you're putting the burden on the user to guess what went wrong.

Robust

Your content must work with assistive technologies and stay interpretable across browsers, devices, and updates.

Focus on:

• Semantic HTML: Use headings, lists, buttons, links, and landmarks for their intended purpose.
• Assistive technology compatibility: Test key workflows with screen readers and keyboard navigation.
• Reliable code patterns: Avoid custom components that look good visually but don't expose state or role properly.
• Template discipline: Accessibility shouldn't disappear when content editors add new pages or modules.

The trade-off here is speed versus resilience. Teams often move faster with custom interface patterns, but if those patterns aren't coded accessibly, you create recurring remediation work every time that component is reused.

Beyond the Checklist AODA as a Business Process

Most accessibility checklists fail because they stop at defects. They tell you what to fix, but not how to keep the organization aligned after the fixes are done. AODA doesn't stop at page-level conformance either. It reaches into planning, documentation, and accountability.

For organizations with 50 or more employees, Ontario guidance requires a written multi-year accessibility plan, updated at least every five years and posted publicly in an accessible format, as described in the Ontario guide to accessibility compliance for industry. That requirement changes the nature of the work. Accessibility becomes part of governance.

What an ongoing AODA program looks like

A durable program usually includes these operational pieces:

1. Planning Define scope, ownership, standards, and review cycles. Include websites, documents, media, forms, and third-party tools.

2. Training Content teams, designers, developers, QA staff, and project managers all affect accessibility. If only the developer gets training, issues keep returning through content and design decisions.

3. Testing and remediation Combine automated scans with manual checks of real user flows. Then assign fixes by severity and business impact.

4. Documentation Keep records of audits, issue logs, remediation status, accessibility statements, design standards, and governance decisions.

5. Maintenance Recheck accessibility after redesigns, CMS migrations, plugin changes, and major content updates.

AODA compliance matures when accessibility becomes part of publishing and release management, not a cleanup step at the end.

What works and what doesn't

What works is ownership inside existing workflows. Teams that add accessibility to design QA, content publishing, procurement review, and release signoff usually sustain progress.

What doesn't work is relying on a one-time audit document that no one revisits. The same goes for assigning accessibility to one person without authority over vendors, templates, or content teams.

If you need a system for scanning, monitoring, reporting, and tracking issues across properties, teams often use platforms that centralize those tasks. One option is WebAbility.io, which provides automated scanning, dashboard monitoring, reporting workflows, and accessibility management features for ongoing compliance operations.

Governance is part of the checklist

Your AODA compliance checklist should include governance questions, not just front-end questions:

• Who approves accessibility fixes before release
• Who owns the public accessibility plan
• Who handles user feedback about barriers
• Who reviews third-party software before procurement
• Who verifies that new content still meets internal standards

That isn't bureaucracy. It's how accessibility survives turnover, redesigns, and vendor changes.

Common AODA Compliance Mistakes to Avoid

Most failures don't come from bad intent. They come from partial implementation. A team fixes visible issues on a few templates, checks a scanner score, and assumes the work is done. Then users hit barriers in documents, forms, mobile navigation, or embedded tools.

Mistake one: auditing pages instead of journeys

Teams often review the homepage, an about page, and one blog post. That misses the tasks users need to complete.

Here's the fix

• Map key journeys: test contact forms, account creation, booking, payment, search, and support flows.
• Check state changes: look at modals, dropdowns, cart updates, validation, and confirmation screens.
• Include error states: many accessibility failures appear only after a user makes a mistake.

Mistake two: trusting third-party components without verification

Plugins, booking widgets, chat tools, payment layers, and embedded forms regularly introduce barriers. The vendor may claim accessibility support, but your implementation still needs review.

Here's the fix

• Test the live implementation: don't rely only on vendor documentation.
• Review contracts and procurement: ask how updates are handled when issues are found.
• Keep alternatives in mind: if a tool blocks access, the business process needs another path for the user.

If a third-party tool breaks an essential task, users won't care that the code belongs to someone else. They experience it as your website.

Mistake three: treating PDFs and uploads as outside the website

AODA obligations don't become easier because content lives in a downloadable file. Teams often publish brochures, forms, reports, or menus that are hard to use with assistive technology.

Here's the fix

• Audit uploaded documents: especially high-traffic and required-use files.
• Prefer HTML for core information: policies, service details, and instructions are often more maintainable on web pages.
• Set content publishing standards: don't let inaccessible files bypass review.

Mistake four: calling the project complete too early

A scanner run is helpful, but it isn't a final answer. Accessibility issues often emerge undetected when editors add new content, designers revise components, or developers swap libraries.

Here's the fix

• Add recurring reviews: especially after major releases and content changes.
• Make accessibility part of QA: not a separate project waiting for budget.
• Document repeat offenders: recurring issue types usually point to training or design system gaps.

How to Verify and Report Your AODA Compliance

Verification should produce evidence, not assumptions. A sound review process checks whether the site meets your internal standard, whether users can complete key tasks, and whether the organization can document its compliance work if asked.

This usually works best as a layered process.

Step one: run automated checks

Automated scanning helps surface repeatable issues such as missing alt text, empty links, low-level markup problems, and some form or heading errors. It won't catch everything, but it's efficient for breadth.

This kind of dashboard view helps teams manage recurring review work across websites and templates:

Step two: manually test priority journeys

Manual testing is where real confidence comes from. Review your highest-risk and highest-value flows using keyboard navigation, zoom, screen-reader-informed checks, and plain user observation.

Prioritize:

• Revenue or service actions: booking, buying, applying, registering
• Contact and support forms: these are often the first place barriers show up
• Navigation and search: if users can't find content, the rest doesn't matter
• Media and documents: especially if they're required to complete a task

Step three: document what you found

Your records should show what was reviewed, what issues were identified, what was fixed, what remains open, and who owns the next action. Keep this in a format your legal, compliance, and digital teams can all read.

If your team needs a starting point for that workflow, WebAbility.io's guide for compliance is a practical reference for organizing reporting documentation.

Step four: prepare for formal reporting

For organizations that must file accessibility compliance reports, the important thing is consistency. Don't wait for filing time to reconstruct what happened over the last cycle. Keep supporting records as work happens.

A useful reporting file usually includes:

• Your accessibility policy and process notes
• Evidence of reviews and remediation
• Ownership for unresolved items
• Public-facing accessibility materials where applicable
• Version history for plans, templates, and standards

Good reporting is a byproduct of good operations. If the records are painful to assemble, the process probably isn't mature enough yet.

AODA Compliance Frequently Asked Questions

Does AODA apply only to the homepage or main website pages

No. AODA website work should be approached across templates, user journeys, forms, media, and supporting content. If a user needs a document, portal, embedded tool, or transactional flow to use your service, that experience belongs in your checklist.

What about third-party content we don't fully control

Treat third-party tools as part of your digital service. Review them before launch, test them in context, and keep a process for handling accessibility issues when they appear. If an essential task depends on an inaccessible vendor component, you still need a workable response for users.

Is AODA compliance a one-time project

No. In practice, it works as a cycle. You plan, audit, remediate, document, review, and repeat. That's the only model that holds up when websites keep changing.

How often should we review our website accessibility

Use a recurring schedule and also review after significant site updates. AODA checklist work is easiest to manage when accessibility is built into releases, content updates, and governance instead of being saved for occasional cleanup.

Is AODA the same as ADA

No. They are different legal frameworks in different jurisdictions. If your organization serves multiple markets, you may need a compliance approach that accounts for more than one legal regime while keeping one practical accessibility standard for your digital teams.

---

If you need a structured way to manage accessibility across audits, remediation, monitoring, and reporting, WebAbility.io provides tools and services that support ongoing compliance workflows for AODA, WCAG, ADA, Section 508, and related standards.