Insights

What Data Does EasyNav Collect About Your Visitors?

None. The first technical decision I made when designing EasyNav was that the tool should not have a database of visitors. Not a small one. Not an anonymized one. None at all.

That sounds like a marketing claim, so let me explain what it actually means and how it works.

What EasyNav Does Not Have

EasyNav does not set cookies on your visitors’ devices.

EasyNav does not log who visited your site, when they visited, how long they stayed, or which controls they used.

EasyNav does not send any data about your visitors to our servers.

We do not have a database of your visitors that could be subpoenaed. We do not have a breach surface that could expose your visitors’ preferences. There is nothing visitor-specific to leak, because there is nothing visitor-specific to collect.

How a Visitor’s Preferences Are Remembered Without a Server

The honest question is: if EasyNav remembers a visitor’s preferences for next time, where are those preferences stored?

The answer is the visitor’s own browser. Every modern browser includes a small piece of storage called localStorage that belongs to the website the visitor is on. EasyNav writes a short string to this storage. The string says something like “this visitor prefers 18-pixel text and high contrast on this site.” That is all of it. The next time the visitor returns, EasyNav reads the string back and applies the preferences.

The data never leaves the visitor’s computer. We cannot see it. You cannot see it. Our servers do not receive it. If a visitor clears their browser data, the string is deleted and EasyNav forgets the preferences. The visitor sets them again on the next visit.

This is the same mechanism a browser uses to remember which sites a person has logged into and which articles they have read. It is older than most accessibility widgets. EasyNav uses it because the alternative, sending preferences to a server keyed to a visitor identifier, is the part of the typical accessibility widget that creates the privacy problems in the first place.

What the Widget Connects To

The widget runs entirely from the visitor’s browser. It is worth being precise about what that means on the network, because this is where most tools in this category quietly differ from their marketing.

EasyNav is sold as a copy of the code you install on your own site, with your settings (trigger color, icon, panel position, enabled features) built into the file. When a page loads, the visitor’s browser loads that file from your site the same way it loads your other scripts. Nothing is fetched from our servers, because the widget never talks to them.

That is the entire network story: your site serves the file, and nothing else happens. There is no conversation between the widget and our servers at all. After the page is loaded, the widget runs locally from the visitor’s browser, and nothing a visitor does inside the panel triggers a request.

A Note on Analytics

EasyNav counts nothing. There is no analytics mode, no usage beacon, and no phone-home in the file you install. If you want to measure how often visitors open the widget, you can wire that into your own analytics, but the copy we ship does not report anything to anyone, including us.

What This Means If You Run a Sensitive Practice

The visitors who adjust an accessibility tool are often doing so because of something they would not normally share. A patient managing a migraine. A reader with mild cognitive symptoms. A visitor who just got an unsettling diagnosis and is trying to read the next page through tired eyes. The act of adjusting contrast is sometimes itself private information.

For a dentist, an attorney, an estate planner, a hospice, a child and family service organization, this matters. When a visitor changes the contrast on your site, that adjustment is not logged anywhere we can see, anywhere you can see, or anywhere an ad network can buy. The visitor’s vulnerability stays the visitor’s.

A note on compliance, because this is where the marketing copy in this category usually overreaches. EasyNav does not process protected health information under HIPAA because it does not process any visitor information at all. EasyNav does not process personal data under GDPR for the same reason. We are not telling you that adding EasyNav makes your overall site HIPAA-compliant or GDPR-compliant. The rest of your site does whatever it does. We are telling you that EasyNav itself is not a new thing for you to document, audit, or worry about.

If you want to read what counts as personal data under GDPR, the ICO’s plain-language explainer is the clearest source.

The Honest Tradeoffs

A no-server design has limits worth naming.

Preferences do not sync across devices. If a visitor uses your site on a phone and a laptop, they set their preferences twice, once per device. A server-backed design could remember those preferences across devices, but only by knowing who the visitor is. We chose the privacy.

Preferences are erased when browser data is cleared. Visitors who clear their cookies and storage regularly will reset EasyNav with everything else.

We have no usage data to share. If you want insight into how often the widget is opened or which controls your visitors use most, we cannot tell you, because we do not see it. Your copy of the widget reports nothing to us.

We cannot offer per-visitor support. If a visitor writes in saying “the contrast button isn’t working,” we have no record of their session to debug from. We ask them to describe what they saw, the same way an old-fashioned customer support call would.

These are real tradeoffs. We chose them because the alternative is to become the kind of tool that knows things about your visitors that your visitors did not choose to share.

Verify It Yourself

If you want to verify the privacy claim before you install, the simplest check is to add EasyNav to a copy of your site, open your browser’s developer tools, and watch the network tab. You will see your own site serve the widget file on page load, and nothing else: no calls to our servers, no beacons. Everything a visitor does inside the panel runs in their browser and generates no traffic, with one narrow exception worth naming: if a visitor enables the dyslexia-friendly font, the font file itself loads from a public CDN (jsDelivr). That request fetches a font and carries nothing about your visitor or your site.