[Screen reader mode, JAWS and NVDA] Arrow keys in the slash command menu move the selection but write nothing

Summary

In screen reader mode, the arrow keys in the slash command menu move the selection, but Claude Code writes nothing at all to the terminal. A screen reader user has no way to know which item is selected, and therefore which command Tab or Enter will complete.

Environment

• Claude Code v2.1.292
• Windows 11, PowerShell / pwsh / wsl, a ConPTY-based terminal
• CLAUDE_AX_SCREEN_READER=1 (banner: [Screen Reader Mode: on via env]), CLAUDE_CODE_ACCESSIBILITY=1, CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1
• Observed by a blind user with both JAWS 2026 and NVDA 2026.1.1

Steps to reproduce

1. Start claude in screen reader mode.
2. Type / in the input. The list of commands is drawn above the input.
3. Press Down three times, then Up once.
4. Press Tab.

Expected

Each arrow makes the selected item perceivable in the text itself, without relying on colour, and the cursor stays on the input caret.

Actual

Measured by recording the terminal's output stream after each key:

• Each Down and Up arrow produces zero bytes of output. No cell of the screen changes, neither text nor attributes; the cursor does not move; the title does not change.
• The selection does move internally: Tab without any arrow completes the first item, while Tab after Down x3 then Up completes the third item.
• With screen reader mode off (axScreenReader: false, same session settings otherwise), each arrow redraws the list with a ❯ marker and a colour on the selected item. Only screen reader mode loses the selection.

Suggestion

The accessibility documentation says that in screen reader mode, menus normally navigated with the arrow keys become numbered lists, and that the terminal cursor stays on the input caret. The slash command suggestions are an exception to the first: the arrows still move the selection, and nothing is written. A numbered list would not fit there, since digits typed go to the input. A text marker would: on each arrow, redraw only the row that loses the selection and the row that gains it, with a textual mark on the selected one, as the session view already does with its selected, prefix. The cursor stays on the input caret, as documented, and any screen reader that reads new terminal output gets the selected item, braille displays included.

The @ file menu was not measured and may share the issue.