-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
- Open the app and navigate to the sidebar containing projects and threads.
- Use Tab / Shift+Tab / Arrow keys (or a screen reader such as NVDA, JAWS, or VoiceOver) to focus a sidebar item.
- Try to open the context menu using standard keyboard methods:
• Context Menu key
• Shift + F10 - Observe that no context menu opens.
- Try to access sidebar-only actions such as:
• Remove project
• Copy path - Compare this with mouse behavior:
• Right-click on the same sidebar item
• The context menu appears normally
Expected behavior
When a sidebar item is focused, users should be able to open its context menu using standard keyboard triggers:
• ContextMenu key
• Shift + F10
The menu should:
• Open reliably for the currently focused item
• Be announced and operable for screen reader users
• Be positioned consistently (ideally anchored to the focused element)
• Expose the same actions currently available via right-click
This ensures keyboard-only and assistive technology users can access all sidebar actions without needing a mouse.
Actual behavior
Sidebar context menus can currently only be opened via mouse right-click.
As a result:
• Keyboard-only users (Blind users) cannot access sidebar context actions
• Screen readers cannot trigger these menus through expected keyboard interaction
• Important actions such as Remove project, Rename, and Delete are effectively unreachable
There is no alternative accessible entry point for these actions.
Impact
Blocks work completely
Version or commit
No response
Environment
No response
Logs or stack traces
Screenshots, recordings, or supporting files
No response
Workaround
As a temporary workaround, I fixed this in my local clone by updating apps/web/src/components/Sidebar.tsx so the existing sidebar context menus can also be opened from keyboard focus using Shift+F10 / ContextMenu, not just mouse right-click. Specifically, I added that handling in the thread item onKeyDown path and in handleProjectTitleKeyDown, where I prevent the native browser menu, compute the focused element position with getBoundingClientRect(), and call the existing context-menu open logic anchored to the focused row/title. For threads, I kept the existing single-select vs multi-select menu behavior intact. I also added the small related callback dependency update needed for the project handler. Since you mentioned contributions aren’t being accepted right now and suggested opening an issue first, I’m documenting it here that way.