Message link context menus do not receive focus with screen readers on Windows #10390

Activity

1. juliusmarminge commented on Sep 6, 2026

   

   juliusmarminge

   on Sep 6, 2026

   Member

   More actions

   Triage

   Confirmed in current desktop source. This is a real accessibility bug, not a support/setup issue.

   Message-link right-click already goes through a custom desktop menu (ChatMarkdown → showExternalLinkContextMenu → LocalApi.contextMenu.show → desktopBridge.showContextMenu). Applications / Shift+F10 fire that same contextmenu handler. The request then drops the invocation source:

   • DesktopBridge.showContextMenu / LocalApi.contextMenu.show only accept items + position (packages/contracts/src/ipc.ts).
   • IPC ContextMenuInput is { items, position? } (apps/desktop/src/ipc/methods/window.ts).
   • ElectronMenu.showContextMenu calls menu.popup() with window, optional x/y, and callback only (apps/desktop/src/electron/ElectronMenu.ts). There is no sourceType anywhere on this path.

   Electron 43 already supports popup({ sourceType }) on Windows/Linux. When it is omitted, Chromium treats the menu as mouse-opened and does not select the first item, so NVDA browse mode never moves onto the options. That matches the isolated Electron comparison in the report.

   The same contract is used by other desktop menus (file chips, sidebar, media). File chips already special-case clientX/Y === 0 for keyboard placement, but they still do not forward a source. This issue can stay scoped to message links; the fix belongs on the shared menu request.

   Not upstream: Electron already exposes the API. T3 just never sends the keyboard source.

   Related

   • Nearby NVDA work, not a duplicate: [Bug]: Screen reader users cannot select composer suggestions #10153 and fix(web): make composer suggestions usable with screen readers #10154 (composer suggestions)
   • Nearby keyboard a11y, different surface: fix(web): make sidebar project actions reachable by keyboard and screen reader #5521

   Next step

   Forward the keyboard source through the existing showContextMenu request and pass it to menu.popup(). Confirm with NVDA browse mode on the Windows desktop app (Applications / Shift+F10 on a message link). No further reproduction notes needed for the source gap.
2. juliusmarminge

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   on Sep 6, 2026
3. akj

   changed the title [-]Message link context menus do not receive focus with NVDA on Windows[/-] [+]Message link context menus do not receive focus with screen readers on Windows[/+] on Sep 6, 2026