eleven / messenger Public

docs: accessibility statement — commit to WCAG 2.2 AA (#570)

Adds docs/accessibility.md (the standard, why 2.2 AA, the practical bar
for UI changes, honest current status, feedback channel), links it from
the README, and adds a Conventions bullet to CLAUDE.md so the bar applies
to every UI change. The full audit is tracked in #569.

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

Paul Campbell 4 months ago 0a2117fa4646a99a860243e2c4c366d0a3ce3e7d parent d78de06

3 files changed, +89 −0

CLAUDE.md +8 −0
README.md +8 −0
docs/accessibility.md +73 −0

diff --git a/CLAUDE.md b/CLAUDE.md

index 2078d86..46b6231 100644

--- a/CLAUDE.md

+++ b/CLAUDE.md

@@ -242,6 +242,14 @@ open with the note itself) carry the 🤖 on their first line.

render inline, occupying layout space — nothing overlays content someone may

be reading or about to tap. Existing floating-`#toast` uses migrate to

inline feedback as they're touched (see `docs/onboarding-and-home-server.md`).

+- 🤖 **Accessibility is a shipping requirement — WCAG 2.2 AA** (statement:

+ `docs/accessibility.md`). New/changed UI is keyboard-operable with visible,

+ managed focus; icon-only controls are labelled (give DOM nodes their ARIA as

+ you build them); contrast holds in light *and* dark; drags/swipes have

+ non-drag alternatives and ≥24px targets; ambient motion (smoke/motes etc.)

+ respects `prefers-reduced-motion` / Reduce Motion; state is never color

+ alone. Native views carry accessibility labels/traits and survive the

+ largest Dynamic Type sizes.

- **Token-gate every data endpoint** with `s.tokenOK(token)` (or the equivalent

invite check) — messages, uploads, blob downloads, unfurl, push subscribe.

- **Pull pure logic into a testable module** rather than burying it in DOM code,

diff --git a/README.md b/README.md

index 87dc5c8..17446fa 100644

--- a/README.md

+++ b/README.md

@@ -330,6 +330,14 @@ WebSocket `msg` frame — **it never sees the plaintext, the private key, or the

thread key.** Keep those on the calling host, never on the server, so the server

holds only ciphertext it can't open (the message-content guarantee above).

+## Accessibility

+Eleven Messenger commits to **[WCAG 2.2 Level AA](https://www.w3.org/TR/WCAG22/)**

+across the web surfaces, and to the same bar on iOS/Mac via VoiceOver, Dynamic

+Type, and Reduce Motion support. The full statement — what the commitment means

+for UI changes, and where we honestly are today — is

+**[docs/accessibility.md](docs/accessibility.md)**.

## Tests

```sh

diff --git a/docs/accessibility.md b/docs/accessibility.md

new file mode 100644

index 0000000..0ccf31e

--- /dev/null

+++ b/docs/accessibility.md

@@ -0,0 +1,73 @@

+# 🤖 Accessibility

+Eleven Messenger is for groups of real people — families, friends, small teams —

+and that only works if everyone in the group can actually use it. This page is

+our accessibility statement: the standard we hold ourselves to, what that means

+in practice, and where we honestly are today.

+## The commitment

+**All web surfaces target [WCAG 2.2](https://www.w3.org/TR/WCAG22/) Level AA.**

+That covers the chat client itself, the mini-apps, the join/invite/onboarding

+pages, the admin console, and the home server pages.

+**The native iOS and Mac apps target the same bar**, interpreted through

+[WCAG2ICT](https://www.w3.org/TR/wcag2ict-22/) and Apple's platform

+accessibility features: full VoiceOver support, Dynamic Type, Reduce Motion,

+and Increase Contrast.

+Why WCAG 2.2 AA:

+- **2.2 is the current W3C Recommendation** — committing to an older version

+ (2.0/2.1) would be committing to yesterday's bar, and 2.2 AA is backwards

+ compatible with 2.1 AA (it adds criteria; the only removal, 4.1.1 Parsing,

+ is obsolete).

+- **AA is the level the world converges on.** Legal and procurement baselines —

+ the EU's EN 301 549 (European Accessibility Act), US Section 508, ADA case

+ law — all reference Level AA. Meeting 2.2 AA satisfies all of them.

+- **AAA is not a blanket target by design** — the W3C itself says AAA cannot be

+ satisfied for all content. We adopt individual AAA criteria where they're

+ cheap and kind (e.g. generous contrast, no timing pressure), but AA is the

+ commitment.

+## What this means for anyone changing the UI

+The bar for new and changed UI, web and native alike:

+- **Keyboard first.** Every action reachable and operable by keyboard, with a

+ visible focus indicator. Panels, menus, sheets, and the lightbox manage focus

+ on open/close and never trap it. The sticky composer and headers must not

+ obscure the focused element (2.4.11).

+- **Everything has a name.** Icon-only buttons get labels; menus and dialogs

+ get proper roles; form fields get real labels. We already build DOM nodes

+ instead of `innerHTML` — give those nodes their ARIA at the same time.

+- **Gestures have alternatives** (2.5.7): anything done by dragging or swiping

+ (to-do reorder, swipe-to-reply) also works with simple taps/clicks, and touch

+ targets are at least 24×24 CSS px (2.5.8).

+- **Contrast holds in both themes.** AA ratios (4.5:1 text, 3:1 large text and

+ UI components) in light *and* dark — including secondary text, placeholders,

+ and focus rings.

+- **Motion is optional.** Ambient scenes (the smoke-and-motes boot and

+ space-switch), grace-period animations, and transitions respect

+ `prefers-reduced-motion` / Reduce Motion.

+- **Never color alone.** State (unread, online, done, error) is always carried

+ by text or shape as well as color.

+- **Native parity.** iOS/Mac views carry accessibility labels and traits,

+ survive the largest Dynamic Type sizes, and expose row actions to VoiceOver.

+## Where we are today

+Honestly: **partial conformance**. Accessibility affordances exist throughout

+(ARIA attributes across the web client, VoiceOver labels in the native apps),

+but we have not yet completed a systematic audit against 2.2 AA. That audit —

+surface by surface, with fixes landing as small PRs — is tracked in

+[issue #569](https://github.com/elevenmessenger/messenger/issues/569). This

+page's status will be updated when the sweep completes.

+## Feedback

+If something in Eleven Messenger doesn't work with your assistive technology,

+or works badly, we want to know:

+[open an issue](https://github.com/elevenmessenger/messenger/issues) describing

+what you were doing, the platform/AT you use, and what went wrong. Accessibility

+reports are treated as bugs, not feature requests.