You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Accessibility]: Add proper navigation commands and cursor for screen-readers #43771
I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Description
I use OpenCode through the terminal with a screen reader, specifically NVDA, and I have configured the TUI to disable mouse interaction. However, OpenCode is currently very difficult to use with screen readers because the TUI does not provide sufficient information about the current selection or focus.
For example, when navigating through selectable options using the Up/Down arrow keys, I cannot reliably determine which option is currently selected. There is no visible cursor, highlight, or other clear indicator that communicates the current selection to a screen reader.
Other coding agents with terminal UIs, such as Claude Code, Codex, and Antigravity CLI, provide a much clearer indication of the currently selected option. For example, they use a > marker next to the currently focused item:
> Option 1
Option 2
Option 3
This kind of indicator is particularly useful for screen-reader users because it provides a textual representation of the current focus/selection rather than relying solely on visual highlighting or terminal cursor positioning.
In OpenCode, the lack of an equivalent indicator makes many interactive menus and selection interfaces extremely difficult or effectively impossible for me to use with a screen reader. The problem is not simply that the mouse is enabled; even with mouse interaction disabled through the TUI configuration, the interface does not expose enough information about focus and selection.
I would therefore like to request improved screen-reader accessibility throughout the TUI. In particular, it would be helpful if interactive elements exposed their current focus/selection in a way that terminal screen readers can detect, such as a textual > indicator, an accessible focus marker, or another equivalent mechanism.
Ideally, this should apply consistently to menus, dialogs, selection lists, and other interactive TUI components.
I would also appreciate accessibility-related configuration options where appropriate, so users can adapt the TUI to different screen readers and accessibility needs.
A partial workaround for NVDA users: I released an NVDA add-on that reads the / and @ suggestion lists in OpenCode desktop as you move through them with the arrows.
If a list stays silent, the NVDA log (NVDA+F1) has lines starting with slashMenus that name the app and the method used, never your text or the list items; please share them on the add-on issues page.
It covers only the suggestion lists, not the wider navigation and cursor requests in this issue, and it does not work in the terminal version, which exposes nothing to read.
Thanks for the detailed request, @diamondStar35. You're asking for the TUI's menus, dialogs and selection lists to show the current selection as text a screen reader can read, for example a > marker or the terminal cursor on the selected row, plus settings to adapt the TUI for screen readers. Maintainers will consider it.
feat(tui): add screen reader mode #56959: an open PR that adds an opt-in screen-reader mode based on opencode mini. In that mode, menus, question lists and the permission prompt move the terminal cursor to the selected row, which is close to what you describe. It isn't merged, but feedback from NVDA users there may help.
Activity
github-actions commentedon Aug 21, 2026
This issue might be a duplicate of or closely related to existing issues. Please check:
Please review these issues to see if your request is already tracked or if you can add your context there instead.
diamondStar35 commentedon Aug 21, 2026
This issue is not similar to the previously mentioned issues at all. It specificly talks about selection and highlight issues.
vojtapolasek commentedon Aug 27, 2026
I am a blind Linux user, I am willing to test changes. I use Opencode daily.
kamalyaser31 commentedon Oct 10, 2026
A partial workaround for NVDA users: I released an NVDA add-on that reads the
/and@suggestion lists in OpenCode desktop as you move through them with the arrows.Slash Menus 2026.1: https://github.com/kamalyaser31/slashMenus/releases/tag/v2026.1
What it does
/or@and a list opens, NVDA says the list name and the selected item.Works in: ChatGPT (desktop and website), Claude (desktop and claude.ai), OpenCode desktop, and WhatsApp desktop and Web (
@mentions).Install: download slashMenus-2026.1.nvda-addon, open it, and restart NVDA. Source and help: https://github.com/kamalyaser31/slashMenus
If a list stays silent, the NVDA log (NVDA+F1) has lines starting with
slashMenusthat name the app and the method used, never your text or the list items; please share them on the add-on issues page.It covers only the suggestion lists, not the wider navigation and cursor requests in this issue, and it does not work in the terminal version, which exposes nothing to read.
opencodejr commentedon Oct 28, 2026
Thanks for the detailed request, @diamondStar35. You're asking for the TUI's menus, dialogs and selection lists to show the current selection as text a screen reader can read, for example a
>marker or the terminal cursor on the selected row, plus settings to adapt the TUI for screen readers. Maintainers will consider it.Related issues and work:
opencode mini. In that mode, menus, question lists and the permission prompt move the terminal cursor to the selected row, which is close to what you describe. It isn't merged, but feedback from NVDA users there may help.geazi-anc commentedon Oct 31, 2026
Another harness alternative is Pi. It's very accessible for screen readers. I use it daily.
The second option is use OpenCode via web. With OpenCode 2.0, it offers
opencode pair, where it up a web server in your computer.However, definitely these alternatives doesn't replace the real feature in OpenCode TUI to improve accessibility for screen readers.