Insights
We Read the Overlay Fact Sheet. Here’s What We Built.
If you work in web accessibility, you have probably encountered the Overlay Fact Sheet. It is a document signed by hundreds of accessibility professionals and disabled users arguing that accessibility overlay products cause active harm, particularly to blind users and people who rely on screen readers and other assistive technology. The core argument is that overlays interfere with tools disabled users have already configured for their own needs, that automated remediation cannot substitute for genuinely accessible design, and that some products in the category have made compliance claims they cannot support.
We took it seriously before writing a single line of code.
That is not a disclaimer. It shaped every technical decision we made.
Who EasyNav is for
The accessibility conversation, the legal framework, the WCAG guidelines, the fact sheet itself, is rightly focused on blind users, screen reader users, motor-impaired users, and people whose access to the web depends on assistive technology they have spent years configuring. These users have been failed repeatedly by products that claimed to help them and made things actively worse. That failure deserved a response, and the fact sheet is part of it.
Accessible design is not something a widget fixes. Sites have a responsibility to build accessibly from the ground up, and no overlay, including ours, changes that.
But there is a second population whose needs the guidelines cover and the tools rarely reach.
An older donor reading your nonprofit’s annual report whose vision has shifted just enough that 14-pixel body copy requires real effort. The patient with a migraine trying to read care instructions on a bright white background. The dyslexic adult who never got a diagnosis and has no idea software exists to help them read. The volunteer checking your event page on a phone in bright sun. These are real conditions. WCAG addresses them. Most of the websites they land on still get them wrong.
Most of these people don’t use screen readers, won’t file a complaint, and won’t tell you your site is hard to read. They just leave.
EasyNav was built to provide tooling for a population that falls into the gap between standard web design and specialized assistive technology. We aren’t a compliance tool or a substitute for accessible design. We are a set of reading comfort controls for people who face daily friction online but don’t require, or don’t have access to, dedicated assistive technology.
What we built around
The fact sheet documents overlays that inject new ARIA roles, labels, and reading-order hints into existing pages, disrupting the carefully configured workflows of screen reader users who had no problem with the site before the widget arrived. We do not touch your page’s ARIA. We do not modify existing roles, labels, or landmark structure. A screen reader user who could navigate your site before EasyNav was installed can navigate it exactly the same way after.
The fact sheet documents overlays that attach document-level keyboard listeners and intercept events meant for native browser controls, forms, and assistive technology shortcuts. EasyNav attaches exactly one document-level keyboard listener: it watches for the Escape key, only fires when the panel is open, and only closes the panel. It does not capture, block, or modify any other keystroke. Your forms work. Your custom components work. Screen reader keyboard shortcuts work.
The fact sheet documents overlays whose CSS accidentally bleeds into the host page, overriding existing styles in ways the site owner never authorized. EasyNav’s UI lives inside a Shadow DOM, an encapsulation boundary enforced by the browser itself. The button, the panel, and our visual styling cannot accidentally leak out, and your styles cannot reach our panel. When a visitor explicitly enables a feature like high contrast, larger text, expanded line spacing, or a dyslexia-friendly font, the widget applies that change by injecting visitor-scoped CSS into the host page. That is intentional and visitor-initiated. The selectors are scoped (body *:not(#easynav-host)) so our own UI is excluded, and the styles are removed the moment the visitor turns the feature off. A visitor who never opens the panel sees no styling effect at all.
The fact sheet documents overlays that rewrite page content, rearrange DOM elements, and attempt automated remediation of accessibility failures. We do not rearrange your markup. We do not insert elements into your existing content. We do not attempt to fix an inaccessible site. When a visitor turns on Text Size, the widget temporarily applies inline font-size styles to existing elements and restores the original values when the feature is turned off. That is the extent of our DOM modification, and it is fully reversible. If your site has accessibility failures, EasyNav does not mask them and does not claim to fix them.
Our approach
The overlay category has a history of overclaiming. Products have told site owners that a single snippet makes their site fully accessible and protects them from legal liability. That claim has harmed both the site owners who believed it and the disabled users who encountered sites that had substituted a widget for real work.
EasyNav’s job is narrower and more honest. It gives visitors who want to adjust how they read your page a simple way to do that. The responsibility for building an accessible site remains with the site owner. We are not interested in blurring that line.
Check our work
If you have signed the Overlay Fact Sheet or work in accessibility and arrived here skeptically, that skepticism is earned. The category has given you good reasons for it.
Open your browser’s developer tools right now, on this site. EasyNav is installed here. Everything described below is happening on this page while you read.
On the DOM panel: you will see one new element appended to the body, with the id easynav-host, containing a Shadow DOM tree. Your existing elements are untouched. If you turn on Text Size, you will see inline style="font-size: ... !important" appear on existing elements; turning the feature off removes those styles cleanly. No ARIA changes anywhere.
On the network panel: filter for “easynav” or look specifically for widget.js, /api/config, and /api/status. Those are the three requests EasyNav itself makes on page load. The marketing site you are inspecting has its own framework traffic (Next.js, monitoring, and so on) that is not part of the widget and would not appear on a customer’s site. When a visitor opens the panel, you will see one additional POST to /api/usage containing the site ID and the string panel_open. If the site owner has enabled analytics in their dashboard, the server increments an aggregate counter visible to them. If they have not, the request arrives and is discarded without being stored. No visitor identifier is sent in either case, and the request does not describe which controls were used or what was changed.
On the keyboard: Tab through your page with the widget installed. The widget’s controls participate in the normal tab order. No other keystroke is captured or intercepted.
What DevTools cannot tell us is how the widget actually behaves with your specific assistive technology. If you use a screen reader, magnification software, a dyslexia reading tool, or any other tool that interacts with the page, and you notice EasyNav behaving in unexpected ways on this site or anywhere you encounter it, we want to know.
If you find anything that contradicts what we have written here, contact us at hello@easynav.io.