Accessibility

Wintty exposes the terminal grid to UI Automation (UIA), the API that Windows screen readers and automation tools read. A screen reader can read the screen by line and word, follow the caret, and hear new output as it arrives. High Contrast themes apply, and the command palette, the tab switcher and the tab overview all work without a mouse.

Every tier ships this, free and paid alike. See What Each Tier Includes for how the editions differ otherwise.

Each terminal pane publishes one UIA element backed by the live grid, through the standard UI Automation Text pattern. A screen reader can:

• read the visible screen by character, word or line
• read the current selection
• get the on-screen rectangle of any range of text, which is what magnifiers and other tools need to find it

The caret a reader sees is the program's actual cursor, not an estimate from the last text written. It reports the correct position while you edit mid-line, inside full-screen TUI programs, and on the alternate screen. Moving the cursor without printing anything (Left or Home while editing, a TUI repositioning its input field) raises a text-selection-changed event, so the reader follows movement that changes no text.

A split layout reads as separate panes: one terminal element per visible pane, no duplicates.

NVDA and Narrator both speak UIA, so both read the surfaces above. Wintty works with UIA screen readers such as these two. That sentence is the whole claim: there is no screen reader certification behind it.

New output is announced as it arrives, with deliberate limits:

• Only complete lines are announced. A line still being written waits for its newline.
• Several new lines are batched into one announcement, and a very large burst is summarized instead of read line by line.
• A full-screen redraw or a clear announces nothing rather than speaking garbage.

The command palette announces that it opened and how many results matched, and it does not repeat itself while the count stays the same. The announcements were tuned against NVDA specifically: an earlier design re-spoke the element name "Terminal" over every burst of output, and that event no longer fires.

Narrator turns on with Win+Ctrl+Enter. An automated acceptance suite drives the live UIA element tree and asserts the behaviors above: the caret in TUIs, one element per pane, and the announcement limits.

When Windows switches to a High Contrast theme, the terminal surface follows it: the background, text and selection colors come from the system theme instead of your Wintty theme. This is the default behavior. To keep your configured colors while High Contrast is on:

windows-high-contrast = false

The theme browser's own palette was fixed to stay readable under High Contrast, and the option is documented with the other Windows-only settings.

The command palette reaches every command without a mouse: open it, type to filter, Enter to run, and each row carries an accessible name. Ctrl+Tab opens the tab switcher and Ctrl+Shift+E opens the tab overview, both straight from the keyboard. In the Pro tiers the sessions picker answers the arrow keys and Enter as well.

Keybindings are configurable, so you can move any of these onto chords you already know. See Keybindings for the format and the action reference for everything that can be bound.

Read aloud, which speaks selected output in a voice you pick, is a separate Pro feature, not a screen reader.

Screen reader problems are hard to fix from a description alone. When you report one, include:

• which screen reader and version (NVDA, Narrator, something else)
• the program running in the pane when it happened
• what was on screen and what you expected to hear