Skip to content

[FEATURE]:Accessibility mode for screen reader users #8565

Closed as not planned
Closed as not planned

Description

@destructatron

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

At the moment, Opencode is actively hostile to any screen readers trying to use the TUI. Emojis, animations and unicode characters add extra noise the text to speech voice is reading to a blind user, which are only there for visual effects in the first place. An accessibility mode would remove those and replace them with more textual equivalents, for instance the spinner being changed to some text when the AI is working and not constantly updating, as this makes the screen reader's review focus jump to the bottom of the window or close to it every time a text update happens.

Activity

  1. added
    discussionUsed for feature requests, proposals, ideas, etc. Open discussion
    on Jan 15, 2026
  2. added
    opentuiThis relates to changes in v1.0, now that opencode uses opentui
    on Jan 15, 2026
  3. github-actions commented on Jan 15, 2026

    @github-actions
    Contributor

    This issue might be a duplicate of existing issues. Please check:

    Both of these issues address similar concerns about reducing visual noise and clutter in the TUI interface. Your accessibility focus for screen readers is a compelling use case that could strengthen those feature requests. Feel free to ignore if your specific case requires a different approach.

  4. taylorarndt commented on Feb 25, 2026

    @taylorarndt

    what is the status of this issue?

  5. destructatron commented on Feb 25, 2026

    @destructatron
    Author

    I'm not sure honestly. It's got some attention in another issue since this one got mentioned, I have a PR that I've been cleaning up and getting rid of merge conflicts for over the past month, but apart from that, crickets on the PR except for someone else who wants this implemented. It's perfectly good code, I tested it and it works, standards checks pass, etc.

  6. taylorarndt commented on Feb 25, 2026

    @taylorarndt

    Does all the providers work after your changes? is there a way I can try it?

  7. taylorarndt commented on Feb 26, 2026

    @taylorarndt

    Thanks for looking this @kommander did you see the pr that goes with this issue? What can we do to get this merged. #8563 @destructatron I think we are making progress.

  8. destructatron commented on Feb 27, 2026

    @destructatron
    Author

    For now until this hopefully gets merged, the PR is literally just an a11y-fixes branch of my opencode fork. So you can clone opencode from my account, and switch to the a11y-fixes branch. it needs a tui.accessibility entry in opencode.json with values, those values are in the docs for that branch. Also, yeah the providers work. The only thing that was changed was how you navigate dialogs and stuff. Activating them still calls the same functions the normal TUI does, just the way you do it is different and more screen reader friendly.

  9. kommander commented on Feb 27, 2026

    @kommander
    Contributor

    Thank you for your effort here. Doing this in opencode via memoized values and branching explodes complexity and we would not be able to maintain that at the moment. There are efforts to support accessibility features on a lower level in the OpenTUI lib: anomalyco/opentui#423 - there is currently no capacity though.

  10. github-actions commented on Apr 29, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

  11. rayo-alcantar commented on May 21, 2026

    @rayo-alcantar

    This solution seems optimal to me. At the moment the only cli that added this was Gemini CLI, with the --screenReader argument.

  12. king-dahmanus commented on Aug 7, 2026

    @king-dahmanus

    This is an expansion of this feature request to hopefully make it more likely to be implemented:

    The Opencode GUI is not accessible to screen readers, agent messages can't be read and I didn't explore further beyond that to determin the specifics since it's unusable.

    TUI is a bit better. Messages can be read somewhat, agent questions can be answered with some mental gymnastics like remembering that the first option doesn't actually get announced and gets a duplicate of the second option. Also, without an external Addon for the NVDA screen reader that only accidentally improves experience of Opencode because it's just called Terminal Access, we can't actually read the messages without moving the mouse randomly up and down until it focuses on the window and reads the whole screen from top to bottom (every new session alert, every context report, every todo item even when it's actually buggy and shows random bits of outdated statistics instead of a handful of real todo items).

    Here's a list of some issues with accessibility:
    •When a question appears, the first option does not get read even when focused with the cursor using up and down arrow keys.
    •Menus, such as the model selection and session switching, are inaccessible. No announcement of the currently focused item, the only way to know is to read the full terminal until the screen reader interrupts a random line with a recognizable element of the menu in question (fri 31 July, Big Pickle). This approach does not actually tell whether things like "search" are clickable and thus the first item, or whether they are unfocusable headings, so selection entails a lot of mental guesswork.
    •No ability to read the current happenings while the agent is thinking or executing except with a random NVDA addon that only worked by accident and was not designed for Opencode TUI.

    Easy proposal: fix the bugs as they appear, and/or make an accessibility mode for the TUI specifically to trim constantly repeating elements like session info and context, menu accessibility enhancement, etc.

    Hard proposal: remake the GUI to be accessible or have an accessibility mode where everything is properly supported, following the Web Content Accessibility Guidelines' standard, i.e: appropriate use of heading levels for message separation and message content, expandable/collapsable sections in buttons for thoughts and code execution, handling of slash commands, and so on.

    Thank you for this great project, hope this issue gets resolved.
    Regards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

discussionUsed for feature requests, proposals, ideas, etc. Open discussionopentuiThis relates to changes in v1.0, now that opencode uses opentui

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions