An accessibility widget won’t make your website compliant. It can change how a page looks for some visitors, but compliance with Ontario’s accessibility rules depends on how the site is built underneath, and a script sitting on top can’t rewrite that. A widget can still be useful as an extra, it just shouldn’t stand in as a replacement.
What an accessibility widget does
An accessibility widget (or overlay), is a script added to a website with a couple of lines of code. It usually shows up as a small icon in the corner of the page. Clicking it will open a toolbar with options like these:
- larger text and adjusted spacing
- high-contrast or alternative colour modes
- highlighted links, or a bigger cursor
Some vendors go further and say their software scans each page and repairs accessibility problems automatically. That claim is the one to be careful with, and it’s the one a regulator has already looked at.
Why can’t a script fix the code underneath?
In Ontario, the Accessibility for Ontarians with Disabilities Act (AODA) requires the designated public sector and organizations with 50 or more employees to make their public websites meet WCAG 2.0 Level AA, with two exceptions for live captions and pre-recorded audio description. That has applied since January 1, 2021. Our article on AODA website compliance covers who it applies to in more detail.
What the A, AA, and AAA levels mean
WCAG sorts its requirements into three levels. Each level includes everything below it, so a site that meets AA also meets every Level A requirement.
- Level A is the minimum. It covers basics such as alt text for images, and a site that can be used entirely from a keyboard.
- Level AA adds requirements such as a contrast ratio of at least 4.5:1 between regular text and its background, and text that can be resized without breaking the page. This is the level Ontario requires.
- Level AAA is the strictest, with a 7:1 contrast ratio and sign language interpretation for pre-recorded video. The W3C, which publishes WCAG, doesn’t recommend requiring AAA across a whole site, because some content can’t meet it.
On new builds, we recommend WCAG 2.2 Level AA, which goes beyond Ontario’s WCAG 2.0 Level AA minimum, ensuring you are well set for the future.
Much of what WCAG asks for lives in the code and the content, rather than in how a page looks. A form field needs a label a screen reader can announce to those with impaired vision. Every interactive element needs to be reachable and usable from a keyboard, in a sensible order. An image needs alt text that says what the image means in that spot.
A widget loads after the page does and adjusts what it finds. It can make text bigger. It can’t know what your product photo is meant to show, or untangle a menu that was never built to work without a mouse.
What a Widget Can Change
- Text size and spacing
- Contrast and colour modes
- Link highlighting and cursor size
What It Can’t Fix
- Alt text that says what an image means
- Menus and popups that trap the keyboard
- Forms without labels or clear errors
What the FTC found about accessiBe
In April 2025, the U.S. Federal Trade Commission finalized an order requiring accessiBe, one of the best-known overlay vendors, to pay $1 million. The FTC said the company’s claims that its accessWidget product could make any website WCAG compliant were false or unsupported. It also found that accessiBe had presented reviews as independent without disclosing its connections to the people writing them.
The order bars the company from claiming its products can make a site compliant, or keep it compliant over time, unless it has evidence to back that up. It’s a U.S. ruling, and has no bearing on Ontario laws, but it demonstrates the limitation of what these products can do.
Accessibility practitioners have been saying the same thing for longer. The Overlay Fact Sheet, an open letter signed by over 1,000 people, says overlays can’t make a site compliant and can get in the way of the assistive technology disabled visitors already use. Many of the signatories are accessibility consultants with a vested interest in the question.
What we find underneath
We don’t come across widgets on prospects’ websites very often. Although to be honest, that’s mostly because many clients aren’t aware of accessibility at all. The ones who do have a widget often believe it takes care of everything else, as though one line of code were a magic bullet for every accessibility problem on the site.
It’s easy to see why. Turn the widget on and the colours change and the text gets bigger, which looks like proof that it’s working. Most people picture accessibility as a matter of helping visitors with poor eyesight, and that’s an important part of it. It’s a long way from the whole picture, though, and the gaps we find tend to be the ones a toolbar can’t touch.
These are the three we see most often.
- Screen readers and alt text. Visitors who can’t see the page at all rely on a screen reader to read it aloud, including the alt text that describes each image. Writing that text properly takes client input, because it has to say what an image means in context. A widget can’t supply that knowledge.
- Keyboard navigation that only half works. Often it works for part of the page, which is a little like building a maze without giving visitors a way out. Someone tabs through the menu without trouble, then a popup appears with no warning, and they can’t close it or get back to what they were doing.
- Forms. The tab order jumps around, and the labels and error messages are either missing or only make sense to someone who can see the screen clearly.
What if you already pay for one?
When a client already has a widget installed, we start by asking why it’s there and what they hoped it would do. There’s no point removing something without understanding the decision behind it.
If a redesign is planned, we push for building the new site to be accessible with proper coding practices from the start. We’re comfortable leaving the widget in place in the meantime, on the understanding that it’s a stopgap. Once the new site launches, it shouldn’t be needed.
In fairness, widgets aren’t useless. We’ve used accessiBe on some projects as a supplement to a site that was already built to be accessible, and some visitors like being able to adjust text size or contrast for themselves. What we avoid is suggesting it can replace a properly coded site.
What a real fix looks like
When accessibility is a requirement on a project, we include it in the proposal scope. On a redesign, that means building everything to be compliant from the beginning. Building it in never catches everything, though, so before launch we review every site template in detail.
Automated testing tools do part of that review. They’re efficient at finding issues and suggesting fixes. Full compliance still takes manual review of several parts of the site, because some problems only show up when a person works through a page with a keyboard or a screen reader.
Pricing depends on the project, but on average, plan for accessibility to add about 15% to 20% to the project price. The larger the scope, the more pages and templates are usually being built, and each one has to be audited.
How We Build for Accessibility
- 1Scope it in the proposal
Accessibility is planned and priced from the start, not added at the end. - 2Build to the standard
Templates, colours, and plugins are chosen and coded to meet WCAG. - 3Review every template
Automated tools find the obvious issues, and manual testing finds the rest. - 4Revisit after launch
A regular review catches what new content and changes introduce.
When the brand colours don’t pass
Sometimes a client’s existing colour palette isn’t WCAG-friendly. Brand colours are often muted or very close to each other, and they don’t give enough contrast between text and background to meet Level AA. The contrast requirement for regular text is the same in WCAG 2.0, which Ontario requires, and in 2.2, the current version.
In those cases, we suggest the client consider a rebrand, or at least a refresh of their brand guidelines that adds some colours for the web. That gives us more flexibility with buttons, links, and other design elements, without forcing everything into one or two shades.
Plugins carried over from the old site
Third-party plugins are the other one. We didn’t write them, but they’re often components the client already uses, and they need to come across to the new site. When one isn’t accessible, we usually have to find an alternative that is, or one that can be modified to comply.
Compliance is a direction, not a switch
Launching compliant is one thing. Staying that way is another. Once a site is in the client’s hands, new pages and plugins go up over the years, and errors can pile up when nobody is watching for them. Unfortunately, that’s what happens on a lot of sites.
The clients who are committed to it revisit their site for accessibility every quarter, or at least once a year. No site stays perfect all the time. Fixing what turns up and keeping a log of the changes shows a compliance officer that the work is ongoing and the site is getting better for everyone who uses it.
A decade ago, when accessibility was not required for private sector businesses, we viewed compliance as binary. A site was either fully compliant or unusable. The reality sits somewhere in between, especially on a complex site that’s updated constantly.
During one client project, we talked it through with the team behind Siteimprove, which sells accessibility monitoring software. Their view was that real-world sites can’t always be fully compliant, so the goal should be to keep improving. If a site is 60% compliant this year, aim for 70% next year. The following year, make it a goal to reach the 80% mark. Over time, you get as close to 100% as you can.
Staying Accessible After Launch
That’s a more useful way to think about it than a one-time fix, and it’s the opposite of what a widget promises.
Fix the code, then keep the toolbar if you like
A widget can be a pleasant extra on a site that’s already accessible. It can’t make an inaccessible site compliant, and a regulator has now said as much about one of the best-known products. The work that counts happens in the templates and the content, and then in keeping them that way after launch. Our article on accessibility beyond compliance looks at why that work tends to improve the site for everyone else too.
If you’re not sure where your own site stands, feel free to book a discovery call. We’ll talk through what’s needed and what it would take, with no pitch, and no pressure.
