Accessibility statement
Studycase is a study cockpit for moot-court and mock-trial preparation. This page states our accessibility conformance target, what is implemented and verified today, the gaps we know about (stated plainly, with the measured numbers), and how to report a problem. It is kept honest against our own audit results: every claim below names the mechanism or test that backs it.
Conformance target
We target WCAG 2.1 Level AA. We do not claim full conformance yet — the known gaps section below lists exactly where we currently fall short and what guards keep those gaps from silently growing.
The transcript is the caption surface
For deaf and hard-of-hearing users, the live transcript pane is the product's caption surface, and it is held to caption conformance rules rather than free-flowing text: lines break at clause boundaries at ≤45 characters (a hard ceiling of 52 for documented punctuation-overshoot cases), blocks hold at most 3 lines before continuing in a new block, and shaping never hides, truncates, or reorders a single word of committed testimony. These rules are enforced by property tests over the real demo transcript and by tests against the rendered page itself (tests/captions.test.ts, e2e/a11y8-caption-conformance.spec.ts). New finals are announced to screen readers through a rate-capped polite live region; the in-progress partial line is deliberately not announced (it mutates many times per second and would be pure screen-reader spam mid-sentence).
What is implemented and verified
- Color-independent status — every color-coded state also carries text or an icon: connection badges are words (LIVE / PAUSED / DEMO / …), confidence chips are labels, speaker roles have distinct text labels beside their colors, ruling moments carry ⚖, marks ⚑, warnings ⚠ plus sentences (
e2e/a11y9-color-independent.spec.ts). - Keyboard access, no traps — everything is reachable by keyboard; single-key shortcuts are suspended while any text field or dialog has focus (typing “v” in your notes types a “v”, it never fires the shortcut); dialogs trap focus only while open and always release on Escape (
e2e/shortcuts.spec.ts,e2e/modal-focus-trap.spec.ts). Bindings are listed in the ⌘K palette and the student guide. - Landmarks, names, and axe — panes are labeled landmarks, every control has an accessible name, and axe-core runs against the live cockpit with zero serious violations (
e2e/axe.spec.ts— all rules enforced, including color-contrast). - Reduced motion —
prefers-reduced-motiondisables pulses, entry animations, and smooth scrolling, including the one programmatic smooth-scroll that CSS alone could not catch; no information is conveyed by motion alone (e2e/reduced-motion.spec.ts). - 200% zoom — the layout remains usable with every control reachable at 200% browser zoom, verified at halved-viewport surrogates of both supported breakpoints (
e2e/zoom-200.spec.ts; the surrogate's limits are stated under known gaps). - Contrast, measured not assumed — 47 real foreground/background pairings are parsed live from the stylesheet and checked against WCAG AA ratios on every test run (
tests/contrast.test.ts). All pass. The tertiary-ink and dark-amber shortfalls this page used to disclose were fixed by a deliberate design pass that moved the whole muted ink ladder in both themes; the harness now asserts the AA floor on every pairing instead of guarding documented gaps.
Known gaps — stated honestly
- Zoom testing uses a stated surrogate. Our 200%-zoom checks halve the CSS-pixel viewport (the honest equivalent for layout), but do not model devicePixelRatio raster effects or text-only “large font” zoom, which grows content without shrinking the viewport.
- Screen-reader behavior is not yet verified on real assistive technology. The live regions and announcement rate-caps are unit- and e2e-tested at the DOM level, but a manual VoiceOver / NVDA pass is still pending. We do not claim real-AT verification we have not done.
Report an accessibility problem
If something here is wrong, or you hit a barrier this page does not list, we want to know — accessibility reports are treated as bugs, not feedback. Contact: [FOUNDER — contact address pending]. Please include what you were trying to do, your browser and assistive technology (if any), and what happened instead.
This statement is reviewed whenever the audit results backing it change. Last substantive update: 2026-07-06.