Quicksloth Accessibility Toolbar

No. An accessibility toolbar helps some visitors; it does not make a website conform to WCAG or to the law. Fix your content and code first. The work that matters is in your content and theme: text alternatives for images, a logical heading order, enough color contrast, labels on form fields, and everything usable with a keyboard. Test with real assistive technology where you can. The toolbar is an extra that lets some visitors adjust the page to their needs.

No script or style of the plugin blocks the first paint. It loads about 9 KB of JavaScript and 2 KB of CSS (gzipped); the page rules (about 2.4 KB) and the dyslexia-friendly font (about 100 KB) load only when a visitor turns on a tool that needs them. In our Lighthouse test (mobile, a long page) the score stayed at 100 and Total Blocking Time at 0 ms.

Yes. The toolbar's HTML is the same for every visitor and choices are applied in the visitor's browser, so cached pages work. We tested WP Super Cache (Simple mode) and LiteSpeed Cache with JavaScript minify, combine and deferred loading and CSS combine turned on. If your optimization plugin delays JavaScript until the first interaction (often called "Delay JavaScript execution"), the button appears only after the visitor scrolls, taps or presses a key. To show it right away, add quicksloth-accessibility-toolbar and QSAB_CONFIG to that feature's exclusions.

The tools work through classes on the page's <html> element and the panel lives in a Shadow DOM, so they do not depend on your builder. We tested the block editor on Twenty Twenty-Five and Elementor: text size and the readable fonts reach Elementor widgets, and the toolbar does not load inside the Elementor editor canvas. If the toolbar shows up inside another builder's editor, turn it off there with the qsab_should_load filter (example below).

Yes. With the language setting on "auto", the toolbar follows the language WordPress sets for each page, which is what multilingual plugins change. We tested Polylang in Italian and in Arabic, where the panel mirrors itself for right-to-left. WPML uses the same WordPress setting; we have not tested it ourselves. All texts can be translated on translate.wordpress.org; until a translation for your language exists, the labels stay in English. You can also set a fixed locale, such as it_IT, under Settings → Accessibility Toolbar.

On your server: the plugin settings, the date the plugin was activated (for the one review request) and whether you dismissed that request. Deleting the plugin removes all three. In the visitor's browser: the tools the visitor turned on, in localStorage under the key qsab:v1, and, if they click "Hide toolbar for this visit", one flag in sessionStorage. Nothing is sent to your server or to us. See the Privacy section.

Yes, under Settings → Accessibility Toolbar: untick the tools you do not want under Tools shown; list page or post IDs under Do not show on these pages; hide the button on screens narrower than 768 px; or enter a CSS selector under Use my own button (CSS selector) so your own button or menu item opens the panel instead of the floating button. Developers can decide case by case with a filter, for example to hide the toolbar on WooCommerce checkout pages: add_filter( 'qsab_should_load', function ( $load ) { return function_exists( 'is_checkout' ) && is_checkout() ? false : $load; } );

No account, no API key, no logo or link on your pages (unless you turn on the optional credit line) and no external requests: the script, the styles and the font are served from your own site. Your theme, page builder or other plugins may make their own external requests (for example web fonts); those are not part of this plugin.