The accessibility widget, honestly framed
What the visitor panel does, where choices are stored, how to customize it, and the one thing an overlay widget cannot do for you.
What the widget is
The accessibility widget is a visitor-facing panel served by the same script that runs your cookie banner. There is no second tag to install. A visitor opens the panel, changes a setting, and the page changes immediately.
It exists for a plain reason. Some visitors read more comfortably with larger text, calmer motion, or clearer focus indicators, and most sites give them no way to ask for any of that. The widget gives them one, on your site, without an account and without a round trip to anyone's server.
What it is not
An overlay widget does not make a site WCAG-compliant. UserGuard does not claim that it does, not in the product, not in this article. Compliance comes from remediation, and remediation lives in your markup: the structure, labels, and contrast of the pages you publish. A panel layered on top cannot fix what the markup gets wrong.
What the widget honestly is: assistance for the visitors who want it, plus evidence that you offer it. If you are working toward WCAG conformance, treat the widget as a supplement to that work, never a substitute for it.
What visitors can adjust
The panel offers these controls:
- Text size — scales page text up to 140%.
- High contrast — increases contrast across the page.
- Reduce motion — calms animation and movement.
- Readable font — swaps in a plainer typeface.
- Link highlighting — makes links visually explicit.
- Text spacing — opens up line and letter spacing.
- Focus highlighting — strengthens the visible focus indicator.
- Big cursor and desaturation — optional extras you can enable.
Every control follows one rule: it changes the page, or it is not offered. There are no placebo toggles. Reset all puts everything back the way it was.
Where the choices go
Nowhere. A visitor's settings persist on their own device and are never sent to a server. That is also why the panel never asks for permission: consent exists to govern data leaving the device, and here nothing leaves. The visitor returns, the page remembers, and no record of it exists anywhere but their browser.
Making it yours
The customizer controls how the widget appears on each site:
- Position on the page.
- Colors, to match your site.
- Copy, so the panel speaks in your voice.
- Which features appear in the panel.
One configuration is refused: every control switched off. Saving will not accept it, because a panel that offers nothing is decoration, and the widget does not ship as decoration.
The customizer also links your accessibility statement from the panel. If you do not have one yet, open the site's Documents tab and choose Edit & preview on the statement's row: the document editor is where every document is drafted, previewed beside a live render, and published. See Documents and the editor.
The panel holds itself to the standard
The widget's own interface is built to WCAG 2.1 AA. It is fully keyboard operable, the modal uses a real focus trap, the focus ring stays visible, and label colors are luminance-checked. The reasoning is straightforward: an accessibility panel that keyboard users cannot operate would refute its own purpose.
Turning it on
The widget is a per-site toggle, included on every tier. Enable it for a site and the same script you already installed starts serving the panel. Nothing new to deploy. Turn it off and the panel is gone. What stays on your side is the configuration; what stays on the visitor's side is their choices.