Before you file your AODA report, what should you check?

Our September 29 webinar covered the reporting deadline, website requirements, and the questions organizations are asking as they prepare. Here are the takeaways, tools, and resources to help you move forward.

Has your organization’s website been evaluated against the Web Content Accessibility Guidelines (WCAG)? During our September 29 AODA webinar, 48% of poll respondents said yes, 7% said no, and 45% weren’t sure.

That uncertainty matters. Knowing what has been tested, what needs attention, and who owns the next step helps organizations plan accessibility work and support accurate reporting.

With Ontario’s December 31, 2026 reporting deadline approaching for businesses and nonprofits with 20 or more Ontario employees, we brought together Rina Volovich, CPWA, Certified Accessibility Expert at accessiBe, and Josh Basile, Esq., trial attorney and accessiBe’s Community Relations Manager, to explain what applies and where to begin.

Rina brought her background in web development and accessibility, along with a personal connection to Ontario: she grew up in Toronto. Josh connected the requirements to his experiences navigating websites with assistive technology.

The session built on our AODA resources, which cover reporting, website checks, fonts, colors, and documents. Attendees brought the practical questions: Who needs to file? What if an agency manages our website? Which tools should we use? And where does AI fit?

Watch the full webinar.

Two employee thresholds to understand

For businesses and nonprofits, the reporting and website thresholds differ.

Designated public-sector organizations also have reporting and website obligations, but follow a separate reporting cycle.

For websites covered by the AODA rule, the standard is WCAG 2.0 Level AA, subject to specified exceptions. The January 1, 2021 website deadline has already passed. December 31, 2026 is a reporting deadline, rather than a new date for making those websites accessible.

Our AODA deadline guide explains the distinctions in more detail.

Filing a report requires understanding what supports your answers

As Rina explained during the session, “filing is not the same as an audit.”

The report is a self-assessment of your organization’s applicable accessibility requirements. Preparing it means gathering the relevant information and having someone with authority to legally bind the organization certify that it is complete and accurate.

An audit is not a prerequisite for submission. It can, however, help your organization understand and document its website’s accessibility position.

One attendee asked whether they could prepare the report and send it to their president for certification. Rina explained that different people can handle preparation and certification through the portal’s sharing process.

Identify the certifier early, along with the people responsible for gathering the information behind the answers.

Our step-by-step filing guide walks through the process.

Website accessibility shows up in everyday customer experiences

Josh described barriers that can interrupt a purchase: a dropdown menu he cannot operate, a form he cannot complete, or a checkout that requires help from someone else. Those examples give the technical requirements a practical purpose. People need to navigate, understand information, and complete tasks independently.

Rina explained WCAG’s four principles in that context:

• Perceivable: people can access the information, including through alternatives to visual content.
• Operable: people can use the interface with different input methods.
• Understandable: content and interactions are clear and predictable.
• Robust: the website works with browsers and assistive technologies.

For your team, that means evaluating complete experiences, such as submitting an inquiry, booking an appointment, or checking out, alongside individual pages.

Your questions about keeping accessibility on track

What if we rely on an external developer?

Several attendees raised questions about evaluating a website without an internal development team.

A useful starting point is to ask your provider:

• What pages and customer journeys have been evaluated?
• Which WCAG version and level were used?
• What automated and manual testing was included?
• Which issues remain, who will address them, and how will fixes be verified?

A scan can help you begin that conversation. A broader evaluation helps establish the scope of the work.

As Josh explained, using an agency does not remove the organization’s responsibility for websites and content it controls, including through qualifying contractual relationships.

How do we maintain accessibility when WordPress themes and plugins change?

An attendee described the challenge of maintaining accessibility across a CMS with components from different authors.

The practical takeaway is to make accessibility part of your change process. Theme changes, plugin updates, new forms, and new content can affect how people use the site.

Rina recommended evaluating accessibility after significant changes. Josh also emphasized moving checks earlier into development.

Assign an owner, include accessibility in release reviews, and verify that important customer journeys still work after updates.

Can AI agents evaluate a website and make code fixes?

AI can support accessibility work, including suggesting code changes. A complete evaluation still requires human judgment alongside automated testing. No tool alone can determine whether a website meets accessibility standards.

Two accessFlow capabilities came up during the Q&A:

• MCP server: connects compatible AI clients to accessFlow’s accessibility findings and WCAG-based remediation guidance.
• Code Agent: reviews GitHub pull requests and proposes accessibility fixes in the diff. Developers decide what to accept, reject, or discuss.

Code Agent is available in beta for eligible accessFlow customers. These capabilities help teams address accessibility within development workflows while supporting the broader evaluation process.

How does AODA relate to the Accessible Canada Act?

They are separate laws with different jurisdictions. AODA addresses accessibility in Ontario. The Accessible Canada Act applies to organizations under federal jurisdiction, including sectors such as banking, telecommunications, and transportation.

Your organization’s sector and jurisdiction determine which requirements apply.

Can agency partners offer solutions beyond accessWidget?

Yes. As discussed during the webinar, accessiBe partners can offer solutions across our ecosystem, including developer tools and expert services. The appropriate approach depends on the client’s website, resources, and accessibility needs.

The tools mentioned during the webinar

Attendees asked us to share the tool names after the session. Here they are, organized by the work you need to do.

The contrast and design tools support specific checks; they do not establish whole-site conformance. An accessScan result also covers the page scanned, rather than a complete evaluation of your website.

Start with what you know, then address the gaps

In our webinar poll, 45% of respondents weren’t sure whether their website had been evaluated against WCAG. Finding that information is a concrete first step: locate existing reports, confirm their scope, and identify what still needs review.

From there, assign responsibility, prioritize barriers, and verify changes. Keep those practices in place after you submit the report.

Need help deciding what your website needs next? Talk with our team about evaluation and remediation options that fit your organization.

Book a conversation →

This article provides educational information, not legal advice. Your organization remains responsible for its report and certification.