[UX] Accessibility pass #367

New issue

Open

opened 2026-08-25 20:39:27 +00:00 by claude-bot · 0 comments

claude-bot commented

2026-08-25 20:39:27 +00:00

Contributor

Why

The review surfaced accessibility-adjacent problems incidentally rather than by looking for them: touch targets well under any usable minimum throughout, core Session Shelf interactions available only via keyboard with no alternative, disabled states explained only by title= tooltips (invisible on touch and to screen readers), status conveyed by colour alone in the voting grid, and a "Wiki" control styled exactly like a tab that actually opens a new browser tab.

None of that was the audit's focus, so the real state is unknown. That is itself the finding.

What

A genuine pass during the rebuild rather than a retrofit: keyboard navigability of every flow, focus management in modals and after navigation, semantic landmarks and headings, form labelling and error association, colour contrast and non-colour status encoding, screen-reader announcement of async state changes (a summary finishing processing should be announced, not silently swapped in), and honest interactive semantics — a link that opens a new tab should say so.

Set a target standard explicitly rather than leaving it implied.

Acceptance criteria

A target standard is chosen and stated
Every core journey completable by keyboard alone
Focus managed on modal open/close and route change
Status never conveyed by colour alone
Async state changes announced to assistive technology
Automated checks in CI, plus one manual screen-reader pass of the core journeys

Found in the August 2026 session lifecycle review (#319). Not separately audited in the review — filed because the rebuild is the moment it is cheap, and because several findings point at it directly. ## Why The review surfaced accessibility-adjacent problems incidentally rather than by looking for them: touch targets well under any usable minimum throughout, core Session Shelf interactions available only via keyboard with no alternative, disabled states explained only by `title=` tooltips (invisible on touch and to screen readers), status conveyed by colour alone in the voting grid, and a "Wiki" control styled exactly like a tab that actually opens a new browser tab. None of that was the audit's focus, so the real state is unknown. That is itself the finding. ## What A genuine pass during the rebuild rather than a retrofit: keyboard navigability of every flow, focus management in modals and after navigation, semantic landmarks and headings, form labelling and error association, colour contrast and non-colour status encoding, screen-reader announcement of async state changes (a summary finishing processing should be announced, not silently swapped in), and honest interactive semantics — a link that opens a new tab should say so. Set a target standard explicitly rather than leaving it implied. ## Acceptance criteria - [ ] A target standard is chosen and stated - [ ] Every core journey completable by keyboard alone - [ ] Focus managed on modal open/close and route change - [ ] Status never conveyed by colour alone - [ ] Async state changes announced to assistive technology - [ ] Automated checks in CI, plus one manual screen-reader pass of the core journeys

claude-bot added this to the v4.4.0 - UX Overhaul: Design Exploration & Rebuild milestone

2026-08-25 20:39:27 +00:00

claude-bot added the

enhancement

frontend

labels

2026-08-25 20:39:27 +00:00

claude-bot referenced this issue

2026-09-06 19:30:20 +00:00

v4.4.0 build order: UX Overhaul in six phases, with two review checkpoints #535