Ontario’s Accessibility for Ontarians with Disabilities Act (AODA) sets out accessibility requirements for private and non-profit organisations across the province. Businesses and non-profits with 20 or more employees must file a formal Accessibility Compliance Report by 31st December 2026, and those with 50 or more employees must also ensure their public-facing website meets the WCAG 2.0 Level AA standard. For many businesses trading in Ontario, this is now a legal requirement, not a choice.
Even where a business sits outside those specific thresholds, the underlying case for the work still holds. A website that is difficult or impossible to use with a screen reader or a keyboard alone is excluding a real part of its audience, and accessible sites tend to perform better in search as a result of the same clean structure and clear content that also makes them easier for a screen reader to interpret. The business case exists independently of the legal one.
Once a business starts evaluating their options, running a free accessibility checker on the website is often the first step, and it seems a reasonable one. Enter a URL, and within seconds a score comes back. The problem is that this score frequently has little bearing on whether a visitor using a screen reader or relying on a keyboard alone can use the site. Free checkers can make a well-built website appear to be failing badly, and just as readily pass a site that still has real barriers in it. Neither result tells a business what it actually needs to know.
An automated checker scans a page’s code against a defined set of rules. Typical checks include:
This is useful groundwork, and it runs quickly. What it cannot do is determine whether that code produces an experience that genuinely makes sense to the person using it. A page can pass every automated rule and remain confusing or unusable for someone relying on assistive technology, just as a page can fail on a technicality that makes no practical difference to a real user.
Free tools are generally weighted toward flagging problems, and it is common for one to return a long list of issues on a site that is, in practice, in reasonable shape. This is not always a fair reflection of reality, and it can lead a business to believe its website is in far worse condition than is the case. Results from an automated checker are a starting point, not a verdict.
The reverse problem is equally significant. Automated tools identify patterns in code. They cannot make judgement calls, and several of the questions that matter most are exactly that, judgement calls:
A scanner routinely misses all three, because each depends on how the page behaves in practice, not only on how it is written.
Genuine accessibility testing means experiencing the site the way a person with a disability would. That means moving through the entire page using only a keyboard, and listening to it read aloud by a screen reader such as NVDA, one of the most widely used tools of its kind, to hear how the content is announced rather than how it appears on screen.
This is where the substantive issues tend to surface. Examples we encounter regularly include:
None of these are reliably caught by an automated scan, and each represents the difference between a website that works for a disabled user and one that does not.
This is not to say a free checker has no value. It remains a reasonable first pass, worth running before anything else, provided the results are treated as an indicative starting point rather than a definitive answer.
Many free checkers test against generic best-practice rules rather than being calibrated to the WCAG 2.0 Level AA standard AODA requires, so a pass or fail from one of these tools does not equate to knowing where a business genuinely stands against its legal obligation.
This carries a practical and technical consequence. The Accessibility Compliance Report due on 31st December 2026 is a senior-officer self-attestation, so filing it on the strength of a checker pass means putting a signature to a claim that a proper audit might not support. Should that gap come to light later, the remediation work still has to be carried out regardless, only now with less time before the deadline, and after the business has already declared itself compliant.
For new websites we build on HubSpot Content Hub, our approach extends beyond testing at the point of launch. Every module is coded to be accessible by default, and an accessibility checker built into the page editor validates content as it is published, catching issues introduced through everyday editing rather than relying solely on a single test at launch. This does not replace expert judgement, it supports it, and the capability applies specifically to sites built on this foundation from the outset.
For an existing website on another platform, our approach is the same combination of automated scanning and genuine manual testing described throughout this piece, carried out by our specialists who understand what affects a disabled user, and what does not.