PowerShell Console Host – UI Automation – Custom Prompt Accessibility

Direct Answer

Confirmed behavior: in the legacy console host (conhost.exe) used by both Windows PowerShell 5.1 and PowerShell 7.x, the UI Automation element for the command line reports only the typed input in its Name and Value properties. A custom prompt string is not part of that element, so Narrator and other UIA-based screen readers announce the command without prompt context. Windows Terminal exposes the prompt together with the input, so it is spoken as part of the same utterance.

Not confirmed: no public Microsoft roadmap entry promises prompt text in the legacy host's automation tree. Any change would most plausibly arrive in a Windows servicing update to conhost rather than a PowerShell release, but that is inference, not an announced plan. Plan around the current behavior.

Likely Explanation

The probable cause is architectural. conhost renders the prompt as ordinary console text outside the editable input region, and the UIA provider it implements models only the active input buffer. Text the user cannot edit is treated as decorative and never surfaces in Name or Value. That is consistent with the same omission appearing in both PowerShell 5.1 and 7.x, since both rely on the same host for console UI. Because Microsoft's documentation does not state whether the prompt belongs in the exposed properties, the current implementation cannot be classified as a documented defect.

Interim Strategies

1. Adopt Windows Terminal as the default host. Lowest-risk option and requires no profile changes. On recent Windows 11 builds you can set the default terminal application in Windows Terminal's startup settings; verify the setting exists on your target OS before relying on it.
2. Host PowerShell in your own application. If you ship a tool that must control the experience, host the engine via System.Management.Automation in a custom console application and implement a UIA provider whose Name is the concatenation of the current prompt and the pending input, refreshed before each read. This adds real engineering cost and can affect performance and compatibility with other console applications, so scope it to a dedicated host rather than a system-wide change.
3. Screen-reader-side scripting. Narrator, NVDA, or JAWS scripts can read the prompt line from the text buffer and speak it before the command. This depends on screen-reader console APIs rather than UIA alone and can break if the window layout changes, so treat it as a stopgap.

Verification

Before committing to a mitigation, confirm what your build actually exposes:

1. Identify the host process: legacy sessions run under conhost.exe; Windows Terminal sessions run under WindowsTerminal.exe.
2. With a known plain-text custom prompt active, open Inspect.exe (Windows SDK) or another UIA inspector, locate the command-line element, and check whether Name or Value contains the prompt.
3. Repeat under Narrator: type a command and compare the announcement with and without the prompt.

These behaviors reflect PowerShell 5.1 and 7.x on Windows 10/11 as understood at the time of writing; re-verify on your specific build before shipping anything that depends on them.

One Detail That Changes the Recommendation

Does the custom prompt embed ANSI/VT escape sequences for color? If so, even Windows Terminal or a custom provider may strip or garble them in the automation tree. Test with a plain-text prompt first: if a plain prompt is announced correctly but the colored one is not, simplify the escape sequences or move the prompt onto its own line.