# 🤖 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.