Unix shell and terminal emulator accessibility integration: focus tracking for screen‑reader output

Answer

No. Shells should not implement their own accessibility layer for output announcements. It is sufficient, and correct, to rely on the terminal emulator’s accessibility API. Readline and shells emit plain byte streams to a PTY and have no visibility into how the emulator renders, scrolls or virtualizes the viewport. Any AT-SPI, NSAccessibility or similar calls made inside the shell process would be invisible to screen readers that monitor the emulator’s accessible tree, and would risk duplicate or missed announcements.

Focus tracking synchronization is an emulator responsibility. The emulator must keep the accessible caret at the prompt for input, move the accessible viewport, and expose newly written lines as accessible text for output with appropriate live region semantics. Consistent announcement of new output depends on emulator support for terminal roles, text nodes, caret tracking and live region attributes, not on readline.

Confirmed facts

• Unix shells and the readline library used by bash, zsh and others emit plain byte streams to a PTY. They do not invoke AT-SPI, NSAccessibility or other assistive-technology APIs.
• Accessibility exposure of terminal content is implemented by the terminal emulator. The emulator maps VT sequences to an accessible object tree and caret, and is the entity that can emit live-region or text-change notifications to the platform accessibility bus.

Likely explanation

• Shell-level accessibility would be ineffective and non-portable. A shell cannot know how the emulator renders, scrolls or virtualizes the viewport.
• Differences across xterm, GNOME Terminal/VTE, iTerm2 and others explain inconsistent announcement behavior. Emulator version and desktop stack determine AT-SPI and NSAccessibility support.
• Readline modifications would be process-local and would not be seen by screen readers that listen to the emulator’s accessible tree.

Minimal steps to verify in this case

1. Run the same shell session under two different emulators on the same OS with a screen reader enabled. Compare announcements for command output and prompt redraw.
2. Inspect the accessible tree for terminal roles, text nodes and caret position with the screen reader active to confirm the emulator is the source of announcements.
3. Check whether readline keystrokes and prompt redraws change accessible caret attributes in the emulator’s accessibility tree, indicating emulator handling of input focus.

One missing diagnostic detail that changes the recommendation: which emulator, desktop stack and screen reader version are in use. AT-SPI and NSAccessibility support for terminals is version-sensitive, and advice on live region behavior depends on the specific combination.