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

[akj]

What happened

Opening a message link's context menu in NVDA browse mode does not move focus to its options reliably.

Diagnosis

A link-focus event can arrive after the native desktop menu opens, leaving NVDA on the underlying link. Preserving Electron's keyboard invocation source helped an initial comparison but did not fix repeated openings in the app.

Steps to reproduce

1. In the Windows desktop app, use NVDA browse mode to read to a message link.
2. Press Applications or Shift+F10.
3. The menu opens, but NVDA does not move to its options. Repeat with another link if the first attempt works.

Environment

T3 Code 0.0.39-nightly.20260906.1303, Windows 11, NVDA.

Evidence

Windows accessibility logging captured link focus after the native menu opened. The reporter confirmed that an in-page ARIA menu worked, then verified the integrated fix with T3's existing menu component on both web and file links.

Fix applied

#10391 uses the existing in-page menu component for message links. No changes to the installed app or NVDA settings.

Filed by Codex, GPT-6, following the T3 triage playbook.

[juliusmarminge]

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.