Overlay widgets vs source-code fixes: what actually makes your site accessible
Accessibility overlays promise quick compliance. Source-code fixes address the root cause. Here is what engineering and procurement teams should understand before choosing an approach.
A founder messages you on a Friday afternoon: "We got a demand letter about accessibility. Can we fix this by Monday?" Someone on the team Googles "website accessibility fix" and finds an overlay widget — a single script tag that promises WCAG compliance in minutes. It sounds too good to be true, and the reason it sounds that way is because it is.
This is not a hit piece on overlay companies. Some of them are trying to solve a real problem — the gap between what the law requires and what most teams have the time or expertise to ship. But the approach matters enormously, and if you are evaluating accessibility tooling right now, you deserve a clear picture of what each approach actually does, what it does not do, and where the industry is heading.
What overlay widgets actually do
An overlay widget is a JavaScript snippet you add to your site. It typically renders a toolbar or floating button that lets users adjust font sizes, toggle high contrast, add focus indicators, or enable a screen reader mode. Some newer overlays go further, using AI to inject ARIA attributes, modify the DOM at runtime, and attempt to relabel elements that assistive technology cannot parse.
The appeal is obvious: no code changes, no sprint planning, no developer time. Drop a script tag into your <head> and check the compliance box.
Here is what happens in practice.
The overlay sits on top of your existing code. Your actual HTML, your React components, your form markup — none of it changes. The overlay patches the rendered DOM in the browser after the page loads. That means the underlying violations still exist in your codebase. If the overlay script fails to load (network issue, ad blocker, script error), those violations are fully exposed again.
More critically, many overlay widgets cannot fix structural accessibility issues. If your heading hierarchy skips from <h1> to <h4>, if your form inputs lack associated labels in the markup, if your modals trap keyboard focus incorrectly — an overlay either cannot detect these problems or cannot reliably fix them at runtime without breaking something else.
What source-code fixes actually do
Source-code remediation means changing the HTML, CSS, JSX, or SCSS that your team wrote. Instead of patching the rendered output in the browser, you fix the file that produces the output. The <img> tag gets an alt attribute in your component. The form input gets a <label> in your JSX. The color contrast ratio gets updated in your design tokens.
This is slower than dropping in a script tag. It requires a developer to review the change, test it, and merge it. But the fix persists — it ships with your code, survives ad blockers, works on every browser and device, and does not depend on a third-party script loading correctly on every page view.
The tradeoff has always been speed. Finding every WCAG violation across a codebase, understanding the fix for each one, writing the code, and opening a pull request takes real engineering time. That is the bottleneck this entire industry exists to address.
The compliance question
If your team is evaluating tools because of AODA, ADA Title II, the European Accessibility Act, or procurement requirements, here is the part that matters most: the legal standard is about what your site does, not what a widget adds on top of it.
Courts and regulators assess whether your digital property meets WCAG success criteria. An overlay that injects ARIA attributes at runtime does not change the fact that your source code produces inaccessible markup. If someone files a complaint and an auditor inspects your HTML, they are looking at what your server sends — and increasingly, what your source code contains.
The National Federation of the Blind published a position statement in 2024 that was blunt about overlays: they do not provide effective accessibility. The statement was specific to a category of products, and it reflected real frustration from users who rely on screen readers daily. Accessibility advocates have been vocal about this for years, and that advocacy has shifted how procurement teams evaluate vendors.
None of this means overlays have zero utility. For a team that genuinely cannot touch their codebase — a legacy system with no active developers, a third-party hosted platform with no source access — an overlay might be the only available short-term option. But it should be understood as a stopgap, not a solution.
What procurement teams are starting to ask
If you work in enterprise software or government contracting, you have probably noticed the questions in RFPs getting sharper. Procurement teams increasingly ask:
Does your tool modify source code or apply runtime patches? Can you demonstrate that fixes persist without a third-party dependency? Do your fixes survive if the vendor relationship ends?
These questions exist because organizations got burned. They bought overlay licenses, reported compliance in their audits, and then faced complaints from users who could not navigate the site with a screen reader despite the overlay being active.
The shift is toward tools that produce artifacts a team owns — code changes, pull requests, commits in their own repository. If the vendor disappears tomorrow, the fixes remain. That is the procurement logic, and it is sound.
Where the industry is heading
The accessibility tooling market is splitting into two clear camps.
One camp focuses on detection: scanning tools that find violations and generate reports. axe-core (maintained by Deque) is the most widely used open-source engine in this space, and many commercial tools — including inklu — build on top of it. Detection is largely a solved problem for the automatable subset of WCAG (roughly 30-40% of success criteria can be fully automated, according to Deque's published research).
The other camp focuses on remediation: actually fixing what the scanner found. This is where the overlay-vs-source-code divide lives. Overlays remediate at runtime. Source-code tools remediate in your repository.
The trend line is clear. Engineering teams want fixes in their codebase, delivered through their existing workflow — pull requests, code review, CI/CD checks. They do not want a runtime dependency that sits between their code and their users.
This is the approach we built inklu around. When inklu scans your codebase, it identifies WCAG 2.2 violations using axe-core plus our proprietary ruleset. Then it generates code fixes and delivers them as GitHub pull requests. Your team reviews the diff, approves or modifies it, and merges. The fix lives in your repo. No script tag, no runtime dependency, no widget.
Evaluating tools: questions worth asking
If you are comparing accessibility tools right now — whether overlays, scanners, or remediation platforms — here are the questions that cut through the marketing:
Does the fix live in my codebase? If the answer is no, understand what happens when the vendor contract lapses or the script fails to load.
What percentage of WCAG success criteria can the tool address? No automated tool covers 100% of WCAG. Anyone claiming full compliance from automation alone is overstating their capability. The best tools are transparent about what they catch and what requires manual review.
How does remediation integrate with my dev workflow? If your team uses GitHub, you want fixes delivered as pull requests — not a dashboard you have to manually translate into code changes. If you use CI/CD, you want checks that run on every push. inklu supports GitHub Actions integration today, with GitLab and CircleCI on the roadmap.
What compliance reports does the tool generate? If you need AODA, ADA Title II, or EAA documentation, ask to see a sample report. inklu generates all three today, with VPAT/ACR support coming soon.
What happens to my source code? This matters for security-conscious teams. inklu purges source code after every scan — your code is never retained. Ask any vendor you evaluate how they handle your code and where it is processed.
The real cost comparison
Overlay widgets typically charge annually, somewhere between a few hundred and several thousand dollars per year depending on traffic and domain count. Source-code remediation tools like inklu use token-based pricing — you can see our pricing page for specifics — where you pay for scans and fixes based on usage.
But the sticker price is not the real cost. The real cost of an overlay is the false sense of compliance it creates. If your team believes the overlay has you covered and stops investing in accessible code, the technical debt compounds silently. When a complaint arrives or an audit happens, the remediation work is larger than it would have been if you had fixed issues in code as you found them.
The real cost of source-code remediation is developer time — time spent reviewing pull requests, verifying fixes, and merging changes. But that time produces permanent improvements. Every merged PR makes your codebase more accessible in a way that compounds positively over time.
Choosing what is right for your team
There is no universal answer. If your codebase is maintained by active developers, source-code fixes are the right approach. You get lasting improvements, no runtime dependencies, and artifacts you own.
If you are in a situation where source code changes are genuinely impossible — a vendor-hosted platform you cannot modify, a legacy system no one maintains — an overlay might be a reasonable interim measure while you plan a migration or rebuild. Just understand what it is and what it is not.
For teams building web applications in HTML, CSS, JSX, or SCSS, this is the problem inklu was built to solve. We scan against WCAG 2.2, generate code fixes with AI, and deliver them as pull requests your team can review and merge. No overlay. No runtime scripts. Just accessible code.
Book a demo at inklu.io or email us at hello@inklu.io.