No skip link anywhere, and focus does not move on navigation (IS-292, IS-296) #780

Closed
opened 2026-09-23 16:36:20 +00:00 by claude-bot · 0 comments
Collaborator

Found checking SH-7's shared patterns in lane 3's last Settings PR (#729).

Two WCAG 2.2 AA requirements the redesign drew and nothing yet does, both app-wide and both the shell's (lane 1's AppFrame), not any one page's:

IS-292 — Skip to the page, over the app bar

grep for a skip link across webapp/frontend/src/ finds none. A keyboard or switch user tabs through the whole app bar and the Contents on every page before reaching its content. WCAG 2.4.1 Bypass Blocks.

The drawing puts it first in tab order, visible on focus, targeting the page's main region.

IS-296 — focus moves on navigation

The dialog half of IS-296 holds (focus into a dialog on open, back to the trigger on close — the new leave prompt does this and is tested). The navigation half does not: on a client-side route change nothing moves focus, so a screen-reader user who follows a link hears nothing and is left wherever focus was — often on a link that no longer exists. The usual fix is to move focus to the new page's h1 (or a focus target at the top of main) after navigation, and announce the new title.

Why these were not fixed in the Settings PR

Both are the frame's, and both change what happens on every screen in the product. They want one deliberate change with its own tests — including in the journeys suite, where the keyboard-only project is exactly the thing that would catch a regression — rather than a line slipped into a settings PR.

a11y-baseline.js stays {}; axe does not flag either (neither is detectable from a static scan), which is why no journey has failed on them.

🤖 Generated with Claude Code

Found checking SH-7's shared patterns in lane 3's last Settings PR (#729). Two WCAG 2.2 AA requirements the redesign drew and nothing yet does, both **app-wide** and both the shell's (lane 1's `AppFrame`), not any one page's: ### `IS-292` — Skip to the page, over the app bar `grep` for a skip link across `webapp/frontend/src/` finds none. A keyboard or switch user tabs through the whole app bar and the Contents on **every** page before reaching its content. WCAG 2.4.1 Bypass Blocks. The drawing puts it first in tab order, visible on focus, targeting the page's main region. ### `IS-296` — focus moves on navigation The dialog half of `IS-296` holds (focus into a dialog on open, back to the trigger on close — the new leave prompt does this and is tested). **The navigation half does not**: on a client-side route change nothing moves focus, so a screen-reader user who follows a link hears nothing and is left wherever focus was — often on a link that no longer exists. The usual fix is to move focus to the new page's `h1` (or a focus target at the top of main) after navigation, and announce the new title. ### Why these were not fixed in the Settings PR Both are the frame's, and both change what happens on every screen in the product. They want one deliberate change with its own tests — including in the journeys suite, where the keyboard-only project is exactly the thing that would catch a regression — rather than a line slipped into a settings PR. `a11y-baseline.js` stays `{}`; axe does not flag either (neither is detectable from a static scan), which is why no journey has failed on them. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
rbrooks/Quest-Board#780
No description provided.