[GH-ISSUE #423] Accessibility #107

New issue

Open

opened 2026-03-02 23:44:36 +03:00 by kerem · 4 comments

kerem commented

2026-03-02 23:44:36 +03:00

Owner

Originally created by @kommander on GitHub (Dec 17, 2025).
Original GitHub issue: https://github.com/anomalyco/opentui/issues/423

Currently screen readers have a hard time with TUIs. My experience making TUIs accessible is limited. I know that some terminal emulators handle it better than others.

But OpenTUI should be able to help out here, by leveraging accessibility APIs on the platform it is running and let Renderables/Elements take aria-labels and other hints that are communicated to the accessibility APIs.

Originally created by @kommander on GitHub (Dec 17, 2025). Original GitHub issue: https://github.com/anomalyco/opentui/issues/423 Currently screen readers have a hard time with TUIs. My experience making TUIs accessible is limited. I know that some terminal emulators handle it better than others. But OpenTUI should be able to help out here, by leveraging accessibility APIs on the platform it is running and let Renderables/Elements take aria-labels and other hints that are communicated to the accessibility APIs.

kerem added the

feature

core

help wanted

labels

2026-03-02 23:44:36 +03:00

kerem commented

2026-03-02 23:44:37 +03:00

Author

Owner

@ghost commented on GitHub (Dec 17, 2025):

I would think it should be able to use windows UIA for windows screen readers. I'm not well versed in the API su I'm not sure how I can help besides testing with NVDA.

@ghost commented on GitHub (Dec 17, 2025): I would think it should be able to use windows UIA for windows screen readers. I'm not well versed in the API su I'm not sure how I can help besides testing with NVDA.

kerem commented

2026-03-02 23:44:37 +03:00

Author

Owner

@kommander commented on GitHub (Dec 17, 2025):

Okay I read up a tiny bit on that for Windows, MacOS would be similar and I guess linux variants as well. This is roughly how I would do this:

RFC: Ship a Windows UIA “provider backend” in the native library (Win32 + COM only)

Implement a UI Automation provider that exposes the OpenTUI renderable tree as a UIA accessibility tree.
Microsoft UI Automation

Rough Architecture

Create a tiny Win32 window (HWND) owned by the OpenTUI process when accessibility is enabled
Handle WM_GETOBJECT and return a UIA provider root for that HWND
Map OpenTUI renderable tree nodes -> UIA elements:
- role/control type (button, list, textbox, menu, etc.)
- Name/HelpText/Value
- bounding rectangles (already available from layout)
- keyboard focus state (already a thing in Renderables and the renderer)
Implement the key provider interfaces for a tree:
- IRawElementProviderSimple (baseline)
- IRawElementProviderFragment + ...FragmentRoot (for navigation)
Implement control patterns per Renderable node type:
- Buttons -> IInvokeProvider
- Inputs -> IValueProvider / ITextProvider
- Lists -> ISelectionProvider / ISelectionItemProvider
Raise the right UIA events:
- focus changed
- property changed (name/value/selection)
- structure changed (children added/removed)
- notification events for toasts/status updates

This would map real semantics (not “terminal text reading”) and would work regardless of alternate screen / ANSI. Exposing options on all Renderables via the base Renderable to set semantics and some lower level methods on the renderer to to for example trigger UIA notifications would allow something like OpenCode to make its complex interface accessible easily, as most would come out-of-the-box.

@kommander commented on GitHub (Dec 17, 2025): Okay I read up a tiny bit on that for Windows, MacOS would be similar and I guess linux variants as well. This is roughly how I would do this: # RFC: Ship a Windows UIA “provider backend” in the native library (Win32 + COM only) Implement a UI Automation provider that exposes the OpenTUI renderable tree as a UIA accessibility tree. [Microsoft UI Automation](https://learn.microsoft.com/en-us/windows/win32/winauto/entry-uiauto-win32) ## Rough Architecture - Create a tiny Win32 window (HWND) owned by the OpenTUI process when accessibility is enabled - Handle `WM_GETOBJECT` and return a UIA provider root for that HWND - Map OpenTUI renderable tree nodes -> UIA elements: - role/control type (button, list, textbox, menu, etc.) - Name/HelpText/Value - bounding rectangles (already available from layout) - keyboard focus state (already a thing in Renderables and the renderer) - Implement the key provider interfaces for a tree: - IRawElementProviderSimple (baseline) - IRawElementProviderFragment + ...FragmentRoot (for navigation) - Implement control patterns per Renderable node type: - Buttons -> IInvokeProvider - Inputs -> IValueProvider / ITextProvider - Lists -> ISelectionProvider / ISelectionItemProvider - Raise the right UIA events: - focus changed - property changed (name/value/selection) - structure changed (children added/removed) - notification events for toasts/status updates This would map real semantics (not “terminal text reading”) and would work regardless of alternate screen / ANSI. Exposing options on all Renderables via the base Renderable to set semantics and some lower level methods on the renderer to to for example trigger UIA notifications would allow something like OpenCode to make its complex interface accessible easily, as most would come out-of-the-box.

kerem commented

2026-03-02 23:44:37 +03:00

Author

Owner

@ghost commented on GitHub (Dec 18, 2025):

Sounds good to me. I'm happy to test once this is implomented

@ghost commented on GitHub (Dec 18, 2025): Sounds good to me. I'm happy to test once this is implomented

kerem commented

2026-03-02 23:44:37 +03:00

Author

Owner

@ghost commented on GitHub (Dec 21, 2025):