Configuring the widget

Configuration lives on the site, not in your code. Changes are picked up by the next page load — no deploy, no cache purge on your side.

Appearance

Adjustments

Every adjustment your plan includes is on by default: the 10 core ones on Standard, all 21 on Pro and Business. Turn one off and it disappears from the panel entirely — no greyed-out control, no dead affordance. Common reasons to disable one:

• Hide images conflicts with a gallery or a product catalogue where imagery is the content.
• Hide buttons hides every button of your own while it is on — form submits, menu toggles, the cookie banner's — so it does little for a web application that is mostly controls.
• Slow cursor is disorienting on an application with drag interactions.
• Blue light filter duplicates a preference your own theme already exposes.

Hide buttons

On Pro and Business. Like Hide images, it hides the page's own buttons — <button> elements, anything with role="button", and submit, reset, image and plain input buttons — in place, so nothing on the page moves; hidden buttons also leave the tab order until the visitor switches it off. Links drawn as buttons hide with them: the widget recognises them by the usual class names (btn, button, wp-block-button__link, elementor-button and the like) and, outside navigation, by their look (a background or rounded border of their own, a button's size and a short label), and they stay links for everything else. Navigation menus, skip links, mail and phone links and larger cards stay. To be explicit, mark a link data-sa-button (<a href="/sign-up" class="cta" data-sa-button>) and it hides with the buttons whatever it looks like. The widget's own button and panel stay too, and so does a button of yours that opens the panel with the onclick="window.__SITEACCESSIBLE__…" snippet shown under Open the panel from your own button. To keep other buttons, put them inside an element with data-sa-keep.

Dictionary

On Pro and Business. With it on, a visitor who double-clicks a word, or selects one with the mouse, a finger or the keyboard, sees its definitions in a small popup beside it; Escape or a click elsewhere closes it. Definitions come from Wiktionary — the English edition, so they are in English whatever the word's language — and the popup credits Wiktionary and links to the word's page, as its CC BY-SA licence asks. The word is explained in the language it was written in (its element's lang, else the page's), falling back to the English entry, never to an unrelated language.

Lookups go through siteaccessible.com: the visitor's browser sends the selected word and its language to us, our server asks Wiktionary and caches the answer, so Wiktionary never sees the visitor, and your Content-Security-Policy needs nothing beyond the connect-src entry for our origin. Nothing else from the page is sent, and selections inside form fields and editable areas are ignored.

Languages

The widget's own interface speaks 29 languages, on every plan. Pick the ones the panel offers and which one is the default; new sites start with all of them enabled. The widget resolves the language in this order: the visitor's saved choice, then the page's own language (<html lang>, so the French pages of a multilingual site get a French panel), then the visitor's browser languages, then your site default — always among the languages you enabled.

Behaviour

Custom CSS

The Business plan accepts a CSS block that is injected inside the widget's own shadow root. It styles the button and the panel only: it cannot leak into your page, and your page's cascade cannot reach into it. The stable class names are .sa-launcher (the button), .sa-panel, .sa-header, .sa-title, .sa-lang, .sa-lang-button, .sa-lang-list and .sa-lang-option (the language picker), .sa-profiles and .sa-profile (the one-tap profiles), .sa-tiles, .sa-tile, .sa-tools (page structure and read aloud), .sa-stop (the floating “stop reading” button), .sa-footer and .sa-reset. The same block also styles .sa-skip, the “Accessibility options” link that appears top-left when a keyboard user tabs into the page.

.sa-panel {
  border-radius: 4px;
}

.sa-launcher {
  box-shadow: 0 0 0 3px #fff, 0 0 0 5px currentColor;
}

Open the panel from your own button

Every plan can open the panel from the page, for example from an “Accessibility options” link in your header or footer. Call window.__SITEACCESSIBLE__.open(); close() and toggle() work the same way. Each returns true when it acted and false when the widget is not running on this page (switched off on phones, or the domain is not licensed), so you can fall back to something else. If the visitor hid the button for their visit, open() brings it back along with the panel. Before the widget has loaded, the methods do not exist yet.

<button type="button" onclick="window.__SITEACCESSIBLE__?.open?.()">
  Accessibility options
</button>