Uh oh!
There was an error while loading. Please reload this page.
fix(web): make sidebar project actions reachable by keyboard and screen reader - #5521
fix(web): make sidebar project actions reachable by keyboard and screen reader#5521akj wants to merge 3 commits into
Conversation
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Uh oh!
There was an error while loading. Please reload this page.
ApprovabilityVerdict: Approved 35109b5 Accessibility fix with limited scope: adds keyboard/screen reader access to sidebar project actions via contextmenu (Shift+F10) and fixes a Safari-specific Ctrl+click edge case. Changes are well-documented and self-contained. You can customize Macroscope's approvability policy. Learn more. |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit ac834d8cfe2aa5eb84b0362d07a937122f168c76. Configure here.
Uh oh!
There was an error while loading. Please reload this page.
…en reader The per-project actions button in the 'Filter threads by project' menu was nested inside a menuitemradio, where ARIA menus cannot focus it: arrow keys move between items, Enter activates the radio, and screen readers flatten the button's label into the item's accessible name. Project settings (remove, rename, grouping) were mouse-only. Open project actions from a contextmenu event on the menu item itself, so Shift+F10 and the Context Menu key work the same way they already do on thread rows. The ellipsis button stays as a mouse-only affordance, hidden from assistive tech so item names announce cleanly. Fixes the remaining half of pingdotgg#1399.
On macOS, Ctrl+click fires contextmenu and Safari also fires a follow-up click on the same element. That click could activate the radio item and change the project filter underneath the settings dialog. stopPropagation on contextmenu cannot block the separate click event, so briefly suppress scope changes after project actions open.
The 500ms suppression window could in principle swallow a legitimate filter selection. Suppress exactly one scope change instead, clearing the flag whenever the menu reopens: a real selection always starts by reopening the menu, so only the Safari ghost click after Ctrl+click can ever be suppressed.
28b51a8 to
35109b5CompareDismissing prior approval to re-evaluate 35109b5
What Changed
Project actions in the sidebar's "Filter threads by project" menu are now reachable by keyboard and screen reader:
aria-hidden,tabIndex={-1}), so screen readers announce each item as just the project name instead of appending phantom "Project actions for…" text.9 insertions, 2 deletions in
apps/web/src/components/SidebarV2.tsx. No visual changes.Why
The ellipsis button was nested inside a
MenuRadioItem(role="menuitemradio"). ARIA menus move focus between items with arrow keys and cannot focus a child of an item, Enter activates the radio, and screen readers flatten the button's label into the item's accessible name — so every project-level action (including Remove project) was mouse-only, and items announced incorrectly to screen readers. Full analysis in #1399 (current-state comment); this fixes the remaining half of that issue.Attaching the handler to the menu item's native
contextmenuevent mirrors the pattern thread rows in the same sidebar already use, and works because Base UI menu items hold real DOM focus while highlighted (verified againstuseListNavigationin@base-ui/react—virtualdefaults to false), so Shift+F10 dispatchescontextmenuat the focused item.UI Changes
No visual changes — the menu renders identically; only keyboard/AT interaction changed. Verified with NVDA on Windows 11 in the Electron dev build: arrowing through the filter menu announces clean project names, Shift+F10/Context Menu key on a project item opens the Project settings dialog with all actions (rename, grouping, remove) reachable, and Enter still selects the filter as before. Mouse behavior (click ellipsis, click item) is unchanged.
Checklist
Note
Low Risk
Localized sidebar menu interaction and accessibility tweaks; no auth, data, or API changes.
Overview
Improves keyboard and screen reader access to project settings from the sidebar Filter threads by project menu, without changing how the menu looks.
Each project
MenuRadioItemnow handlesonContextMenu(e.g. Shift+F10 / Context Menu key) to open the same project settings route as the gear control. The nested settings button stays for mouse users but is removed from the tab order and assistive tech (tabIndex={-1},aria-hidden), so items announce as the project name only.Opening settings sets
suppressNextScopeChangeRefso the follow-up click Safari/macOS emits after Ctrl+click does not change the filter scope under the settings page; the flag resets when the menu opens again, andonValueChangeignores one spurious scope update when the flag is set.Reviewed by Cursor Bugbot for commit 35109b5. Bugbot is set up for automated code reviews on this repo. Configure here.
Note
Make sidebar project actions reachable by keyboard and screen reader
suppressNextScopeChangeRefflag to ignore the trailing scope-change event.tabIndex=-1andaria-hidden=trueso it no longer appears in keyboard/AT focus order; themenuitemradiorole handles accessibility instead.handleProjectSettingscallback accepts a genericHTMLElementevent (click or contextmenu), sets the suppress flag, then navigates to project settings.Macroscope summarized 35109b5.