Vord

Enhancement Proposal

Proposal: Accessibility (WCAG) for the hosted UIs

Vord ships two human-facing UIs — the hosted login / registration / MFA / consent / recovery ceremonies (proposal 0007) and the admin console (proposal 0018) — and no record states an accessibility requirement for either. The hosted login page is the gate to every relying application; if it is inaccessible it locks users with disabilities out of every app that delegates to Vord. This proposal makes accessibility a stated target and a build gate, not a late retrofit.

Motivation

The login ceremony is the most-reached surface Vord has, and it is the one surface a relying party cannot route around. An inaccessible login or MFA flow is both an exclusion of real users and a legal exposure for operators (EN 301 549, Section 508, ADA case law all reference WCAG). Because the ceremony chrome is Vord's — only theming is the operator's (proposal 0007) — accessibility is Vord's responsibility to get right once, for everyone, rather than each operator's to rediscover.

Design

  • Target WCAG 2.2 Level AA for all hosted ceremonies (proposal 0007) and the admin console (proposal 0018). AA is the level regulations reference.
  • Concretely: full keyboard operability with visible focus; programmatic labels/roles on every control in the login, MFA, consent, and recovery flows; sufficient contrast in the default theme; screen-reader-tested authentication, MFA enrolment, passkey, and error/validation flows; support for reduced-motion, zoom, and reflow; and error messaging that never relies on color alone.
  • Branding has a contrast floor. Per-realm theming (proposal 0007) cannot configure foreground/background below the AA contrast ratio — the theming surface is clamped so an operator's branding cannot break accessibility.
  • Passkey/WebAuthn flows (ADR-0020) have an accessible alternate. A user who cannot complete a platform-authenticator gesture is offered an accessible alternate factor.
  • Localization composes with accessibility (proposal 0007): page language is set programmatically; RTL is supported.
  • Accessibility is a build gate. Automated checks (axe-core or equivalent) run in CI for the hosted UIs, plus a manual screen-reader + keyboard pass for each milestone that ships UI surface — the a11y counterpart to the conformance and abuse-case gates (ADR-0028).

Alternatives considered

  • WCAG 2.1 AA — rejected in favour of 2.2 (a superset adding target-size and focus criteria; small delta, current baseline).
  • Level AAA as a blanket target — rejected; some AAA criteria are impractical or conflicting for auth flows. AA, with AAA adopted where it is cheap.
  • "Accessibility is the operator's branding problem" — rejected; the ceremony chrome is Vord's, and the contrast floor keeps operator theming from breaking AA.

Graduation criteria

The hosted login / MFA / consent / recovery flows and the admin console pass automated WCAG 2.2 AA checks in CI and a manual screen-reader + keyboard pass; per-realm branding cannot be configured below the AA contrast floor; passkey flows offer an accessible alternate factor.

Backward compatibility

A contrast floor constrains the branding surface (proposal 0007) — an operator currently configured below the floor would be clamped to it. No API or token change.

Open questions

  • Which automated engine (axe-core vs alternatives), and how to handle its false-positive rate when it gates merges.
  • Whether to produce a formal VPAT / accessibility conformance report for the admin console at a later milestone.
  • Internationalization depth (RTL correctness, pluralization, locale formatting) is related but owned by proposal 0007, the localization/i18n owner for the hosted UIs — tracked there, not here.