WCAG 2.1 AA · keyboard operability · reduced motion · avoided patterns
Accessibility¶
What we've verified, what we're aiming for, and what's still an open question — no hand-waving either way.
Overview¶
Keyboard support, screen-reader labeling, and motion behavior are all checked and confirmed below — not just promised. Color contrast and a full conformance audit are goals we're working toward, and we've kept those two categories clearly separate throughout this page.
WCAG 2.1 AA
The project's stated target — a design goal, not an independent audit.
Editor UI
Keyboard-operable popovers, tab strips, and drag handles.
Reduced motion
Suppressible under prefers-reduced-motion; content is never left invisible.
Avoided by design
Justified text and other known-problem patterns are opt-in, never default.
Editor UI: keyboard operability¶
A closer look at what "keyboard-operable" actually means in the editor.
Every popover and tab strip is properly announced
Screen readers and other assistive tech get real semantic roles and states on every popover and tab strip in the editor — not just visual styling that only sighted mouse users can follow.
Arrow keys move between tabs, not the Tab key
The Layout popover's tab strip follows the WAI-ARIA Tabs pattern: arrow keys (plus Home/End) move between tabs, and only the active one sits in the page's normal Tab order — no hunting through every tab to get where you're going.
Popover fields commit on Enter, cancel on Escape
The same shortcuts people already expect from every other form on the web — no learning curve, no mouse required to confirm or back out of a change.
Fine-tune Motion timing without touching a mouse
Grab the timeline handle with Enter or Space, nudge it with the arrow keys (hold Shift for finer control), and Escape backs out cleanly. See Motion → Customize.
Tooltips work for people who can't see them, too
Every control gets a real accessible name (aria-label), not just a hover hint that only sighted mouse users ever see — so the control is announced correctly whether or not the tooltip itself is visible.
Front-end markup¶
Decorative media never gets in the way of the content
Background images and video overlays are marked purely decorative (aria-hidden="true"), so screen readers skip straight past them to what actually matters on the page.
Responsive hiding behaves consistently for everyone
Content hidden at a given screen size stays hidden the same way for every visitor — assistive technology and sighted visitors are never shown a different picture of the page.
Motion and reduced motion¶
Visitors who ask for less motion get it
Honoring prefers-reduced-motion isn't optional polish here — it's treated as a WCAG 2.2.2 obligation. Site owners choose how: fade only (the default), skip animation entirely, or play everything anyway — that last option is opt-in only and clearly flagged as a WCAG 2.3.3 trade-off, never the default.
Content is never left invisible
If an animation can't run — a script error, a blocked script, a reduced-motion preference — the content still shows up. Nothing on the page depends on an animation succeeding to become visible.
Horizontal-scroll effects don't get a "lite" version — they're off
For a reduced-motion visitor, horizontal-scroll effects aren't throttled or simplified — they simply don't play at all.
The Motion timeline is legible, not just usable
Its text meets WCAG AA contrast requirements, so the timeline reads clearly at a glance instead of relying on precise color vision.
Full detail: Motion → Reduced motion.
Deliberately avoided patterns¶
Justified body text is opt-in, never default
Justified text creates uneven spacing that's harder for many readers to track, which is why it fails WCAG 2.1 SC 1.4.8 (Level AAA). If a site owner turns it on anyway, the Typography panel explains the trade-off in plain terms rather than staying silent about it. See Styles → Gradients.
Known gaps and unaudited claims¶
Checked against the code, with a specific answer either way — not a to-do list.
No automated keyboard or screen-reader test of the full editor, yet
We checked: there's no automated test today that walks the whole editor keyboard-only, or scans it with a screen-reader tool like axe. That's a real, acknowledged gap — not an assumption we're glossing over.
The floating toolbar doesn't announce which section it's editing
The section toolbar is labeled and its buttons are named, but a screen-reader user tabbing through the page has no reliable way to tell which section it's currently attached to. That's a specific, acknowledged gap — not a vague "needs testing" placeholder.
Related documentation¶
The project's stated accessibility target (from the module's own design documentation) is WCAG 2.1 AA. This is a design goal, not the result of an independent audit or automated conformance test suite. Nothing on this page should be read as a formal conformance claim.