InclusaBar

InclusaBar applies its styles at the html element level using CSS custom properties and classes, so it is broadly compatible with Bricks Builder, Elementor, Kadence, and similar builders. High contrast uses filter: contrast() which may interact with complex stacking contexts — test on your specific theme.

The toolbar itself requires JS. However, no content is hidden behind the toolbar; it is purely additive.

Yes — the toolbar uses proper ARIA roles, role=”switch” on toggle buttons, focus management, keyboard trap within the panel, and aria-live for font size announcements.

It adds a floating toolbar with: font size and line height controls (independent steppers), high contrast, reduce motion (with OS preference auto-detection), enhanced focus indicators, reading mode, forced link underlines, a dyslexia-friendly font, grayscale, and a big cursor. Everything is configurable from Settings → InclusaBar (position, button colours and shape, step sizes) and every setting has an individual reset plus a single “Reset All Settings” button.

Yes. Under Settings → InclusaBar → Toolbar Appearance you can set the button colour, the icon colour, and the corner radius — use pixels or a percentage, where 0 is square and 50% is fully round. You can also choose which corner of the screen the button sits in, how far it sits from the edge, and its z-index if it overlaps a fixed header or footer. The button colour is also used for switched-on toggles and keyboard focus outlines inside the panel, so the whole toolbar stays consistent. As you choose the colours, the Settings page shows the contrast between the button and its icon and rates it against the 4.5:1 accessibility target. If it’s too low, a “Use recommended icon colour” button picks white or dark navy for you. You can still save any combination you like, but you’ll see a warning if the contrast is low.

No. There is no telemetry, analytics, or tracking of any kind, and the plugin makes no external network requests. Toolbar settings a visitor changes are stored only in that browser’s own localStorage — nothing is sent to or stored on your server per-visitor. The only data InclusaBar stores server-side is the single inclusabar_settings option holding the admin’s configuration (position, button colours, step sizes, etc.), which you set yourself on the Settings page.

Every release is checked with the official WordPress Plugin Check tool, plus an additional dedicated logic-level security review before it ships. This includes broken access control, privilege escalation, and injection points. Settings are validated and sanitised server-side (whitelisted values, clamped numeric ranges) regardless of what’s submitted client-side.

Uninstalling deletes the single inclusabar_settings option from your database — no other data is left behind. Per-visitor localStorage entries live in each visitor’s own browser and aren’t something the plugin (or its uninstall routine) can reach or clear remotely; they’ll persist until that visitor clears their own browser storage.

Yes. The toolbar’s HTML/CSS/JS is identical for every visitor (it’s built from the admin’s saved settings, not per-visitor data), so full-page caching doesn’t cause stale or incorrect output. Each visitor’s individual toolbar choices live in their own browser’s localStorage, entirely independent of your server-side cache.

Yes. The toolbar and panel work with standard tap interactions (no touch-specific code needed), the panel is sized to comfortably fit real phone screens, and its height is capped to the viewport with internal scrolling — so it never gets cut off or grows taller than the screen on short or landscape mobile viewports.