For developers
You already know what overlays promise. This page is about the rest of what we build.
A scanner that gives you the element, the success criterion and the fix — and tells you plainly which findings no widget can touch. Free, no login for the score, no sales call.
- Scanner works without the widget
- Every finding maps to a WCAG 2.2 SC
- No tracking cookies
3on this component
- Image has no accessible name1.1.1 Non-text Content · A ·
img.product-thumbManual - Interactive element is not focusable2.1.1 Keyboard · A ·
div.add-to-cartManual - Text contrast 3.1:1, needs 4.5:11.4.3 Contrast (Minimum) · AA ·
.price--sale
Two of these three are yours. We are not going to pretend a script can write an alt attribute that means something, or give a div a role it never had.
Illustrative example — not a real scan result.
01 — Start here
Yes, we make an overlay. Here's what we think of them.
You are the audience most likely to close this tab, and the reasons are good ones. So we will deal with them before anything else.
What we agree with
- An overlay cannot make a site conformant. Conformance lives in the markup, and no client-side script rewrites intent.
- Automatically generated alt text is usually worse than none, because it looks like the problem is solved.
- Many assistive-technology users actively dislike overlays, and vendors who ignore that are not listening to the people they claim to serve.
- Throughout 2025, lawsuits kept being filed against sites that already had a widget installed. The widget was never the defence.
Where we land differently
- A user-controlled preference layer — text size, contrast, motion, spacing — is genuinely useful to some visitors, as long as it is offered as a preference and not sold as compliance.
- The damage overlays did to this category came from the marketing, not from the idea of a preference panel. We are trying to keep the second and refuse the first.
- Most of what we build is not the overlay. It is the scanner, the remediation guidance and the audit trail — the parts that assume you are going to fix the code.
The practical consequence, stated plainly: you can use FlexAccesses as a scanner and never install the widget. That is a supported configuration, not a workaround. If your team fixes the code properly, the widget has very little left to do on your site — and we would rather say that here than have you discover it and conclude we were hiding it.
02 — Output
What a finding actually contains.
Not a score and a vibe. Every row carries enough to open the file and fix it.
| Page URL | Where it occurs, with an occurrence count rather than one row per instance. |
|---|---|
| Element / selector | The specific node, as a selector you can paste into devtools. |
| WCAG SC | Criterion number and name — for example 2.4.11 Focus Not Obscured (Minimum). |
| Level | A or AA. We test against WCAG 2.2 AA, including the criteria added in 2.2. |
| Severity | Critical, Serious, Moderate or Minor — as a written value, never colour alone. |
| Legal risk | Separate from severity, because the two do not always agree and your PM will ask. |
| Widget or Manual | The field this whole company is built around. Never omitted. |
| Remediation note | Framework-specific where we know your stack, generic HTML where we don't. |
03 — Fixes
Guidance in your framework, not in the abstract.
"Add an accessible name" is not guidance. This is what a finding hands you.
Snippets, not prose
Plain HTML, React, Vue and Angular. Each one tested against NVDA, JAWS and VoiceOver before it goes into the library, because ARIA that reads correctly in one and not the others is a bug we would be shipping to you.
Hear the difference
An interactive simulator toggles between the broken and fixed markup and shows exactly what a screen reader announces in each case. Useful in review, and unusually persuasive in a meeting with a product owner.
Priority you can defend in planning
Each item carries priority and legal risk as separate values, so "why is this above the redesign" has an answer that is not just your opinion.
<!-- before -->
<div class="add-to-cart" onclick="add()">
Add to cart
</div>
<!-- after -->
<button type="button" class="add-to-cart" onclick="add()">
Add to cart
</button>// before
<div className="add-to-cart" onClick={add}>
Add to cart
</div>
// after
<button type="button" className="add-to-cart" onClick={add}>
Add to cart
</button><!-- before -->
<div class="add-to-cart" @click="add">
Add to cart
</div>
<!-- after -->
<button type="button" class="add-to-cart" @click="add">
Add to cart
</button><!-- before -->
<div class="add-to-cart" (click)="add()">
Add to cart
</div>
<!-- after -->
<button type="button" class="add-to-cart" (click)="add()">
Add to cart
</button>04 — Workflow
Into the tools you already have open.
A finding that lives only in someone else's dashboard is a finding that never gets fixed.
- From free
Ticket export
Findings go to Jira, GitHub, Trello or Asana with the selector, the criterion, the severity and the remediation note already in the body. Scoping becomes an estimate, not an investigation.
- Paid tiers
Scheduled scans and regression alerts
Re-scan on a schedule and get told when something that used to pass stops passing. A dependency bump that removes a label is the classic case.
- Infrastructure
CLI for CI/CD, custom API and webhooks
Fail a build on new critical findings, or push results wherever you keep them. Being straight with you: this sits on the Infrastructure tier today. If gating a pipeline is the reason you are here, tell us — how quickly it moves depends on how many of you ask.
$ flexaccesses scan --url https://staging.example.com --fail-on critical
scanning 42 pages …
✓ 1.4.3 Contrast (Minimum) no new findings
! 2.4.7 Focus Visible 3 new · serious
✗ 1.1.1 Non-text Content 1 new · critical · .hero-banner img
build failed — 1 new critical finding
report: https://app.flexaccesses.com/r/…Illustrative output. Exact flags and command names are not final — do not build against this. Ask us for the current CLI reference before you script anything.
05 — Limits
The ceiling on all automated testing.
Ours included. If a vendor's number is much higher, ask what they are counting.
Automation catches this
- Whether an
altattribute exists - Computed contrast ratios
- Form controls with no programmatic label
- Heading order, landmark structure, document language
Automation cannot judge this
- Whether
alt="image"describes anything - Whether the focus order matches the visual order in a way that makes sense
- Whether a screen reader user can actually complete checkout
- Whether an error message tells the user how to recover
Automated testing reliably detects 30–50% of WCAG 2.2 AA success criteria. That is not a limitation of our implementation — it is a property of static analysis against criteria that are partly about meaning and intent. Treat a clean scan as necessary and not sufficient. The rest is screen-reader testing, keyboard-only walkthroughs, and testing with people who use assistive technology daily.
06 — Us
You are going to check our markup. Please do.
An accessibility vendor whose own product fails is not a vendor, it is an argument against itself.
VPAT for our own product
A Voluntary Product Accessibility Template documenting where our dashboard and widget conform and where they do not. Available on request, including the parts that are unflattering.
The widget's own keyboard behaviour
The panel is reachable by keyboard, does not trap focus, and closes on Escape. A widget that fails this while advertising keyboard navigation would be indefensible.
This page, scanned
We intend to publish this page's own scan result with a permanent link to the report, including whatever is still open. Until that link exists, take the intention as a stated commitment rather than as evidence — you can scan the page yourself in the meantime.
07 — FAQ
Questions, answered honestly.
Does the widget modify my DOM?
Yes, when a visitor turns something on. Text scaling, contrast modes, spacing and motion controls all work by applying styles and, for some profiles, by adding ARIA. That is worth knowing if you have built careful semantics you do not want touched — and it is the single most common developer objection to overlays, so we would rather state it than let you find it. If you do not want it on your site, run the scanner and skip the widget entirely. That configuration is supported.
If I fix everything properly, do I still need you?
Not for the widget, no. If your markup is right, most of what the widget offers is already available through the browser and the user's own assistive technology. What tends to remain useful is the monitoring — sites regress, dependencies change, and a contributor pastes in a div that should have been a button. Buy the part you need. We would rather sell you one thing you use than three you resent.
Can I run this in CI?
The CLI, custom API and webhooks are on the Infrastructure tier today, which is an honest answer rather than a comfortable one. If pipeline gating is what you came for, say so — the roadmap for that capability is driven by how many teams ask. In the meantime, scheduled scans with regression alerts cover a good part of the same need without a build integration.
Will the script hurt my Core Web Vitals?
It is under 30 kb, loads asynchronously and is served from a CDN edge, so it should not block render. We deliberately publish no single page-speed number, because ours would be measured on our stack and not yours. You have Lighthouse and a staging environment — measure it before and after and hold us to your own number.
What does the free tier let me do?
Scan with no login at all for the score and prioritised issue list. A free account — no card, no trial timer — covers one site, 100 scanned pages a month, unlimited widget impressions if you choose to use it, and basic WCAG 2.2 reporting. Enough to evaluate the output on a real project before anyone has to approve a purchase.
Why should I trust a scanner from an overlay company?
Because of the incentive you are worried about, run the other way: a scanner that under-reports the findings a widget cannot fix would make our reports look better and our audits look unnecessary. We label those findings explicitly and we do not hide new ones in monitoring reports. You do not have to take that on faith — scan a page you already know is broken and check whether the manual-fix items are all there.
Scan a page you already know is broken. Check our work.
No login for the score. No card for an account. If the output is not useful to you, that is the fastest way to find out.
Built by people who would rather be corrected than believed.