The widget's own accessibility
How the panel works with a keyboard, screen readers, high contrast and reduced motion, and how it is tested.
On this page
A widget that offers accessibility settings has to be accessible itself. The panel follows WAI-ARIA patterns and is tested in every release.
Keyboard
Everything works without a mouse.
| Keys | What they do |
|---|---|
| AltA | Open or close the panel. Also brings the widget back after “Hide widget”. |
| Esc | Close the panel (or the language list, or read mode); focus returns to where it was. |
| TabShift + Tab | Move between controls. Focus stays inside the panel while it's open. |
| EnterSpace | Press buttons, switches and profile cards; open and close sections. |
| ←→ | Move between the options of a segmented choice. |
| ↑↓HomeEnd | Move through the language list; type a letter to jump to a language. |
What assistive technology finds
The panel uses standard roles and states, so screen readers announce it like any other control.
- The panel is a modal dialog with a focus trap. While it's open, the rest of the page is
inert, so screen-reader virtual cursors stay inside. Escape, the close button or a click outside closes it, and focus returns to the launcher. - Sections are an accordion (
aria-expanded), toggles are switches (role="switch"), profile cards are toggle buttons (aria-pressed), and segmented choices are radio groups. - Steppers announce the new value with its name (“Text size 120%”) and say when a limit is reached. Resetting is announced too.
- The language menu is a select-only combobox with a listbox: arrow keys, Home and End, and type-ahead.
- Touch targets are at least 30 by 30 pixels, and the panel follows the browser's default font size.
- When keyboard focus lands on a page control under the launcher, the launcher steps aside until focus moves on (WCAG 2.4.11). It still covers its corner for mouse and touch users.
- The widget never adjusts itself: text size, spacing, colors and filters apply to the page only, so the panel always looks and works the same.
- It respects
prefers-reduced-motionand Windows High Contrast (forced-colors), where its color filters switch off so the system colors win.
Testing
Every release runs in headless Chrome with axe-core (no violations allowed) and keyboard-only scripts, covering focus handling, reflow at 320 pixels and destroy(). Automated tests can't replace real screen readers, so a manual round with NVDA, JAWS, VoiceOver, TalkBack and Windows High Contrast is asked for before major releases and recorded in docs/at-test-matrix.md. The widget's Accessibility Conformance Report (VPAT 2.5 INT: WCAG 2.2, EN 301 549, Section 508) is in docs/ACR.md; it stays a draft, with the results that need people marked Pending, until that round is recorded.
Accessibility statement
ACCESSIBILITY.md in the repository.