PowerShell
Accessibility mode for PSReadLine
Related: https://github.com/PowerShell/PSReadLine/issues/859
The re-draw that PSReadLine does is only one aspect that affects accessibility (specifically screen readers that scrape the screen buffer). I would be interested in what users would like to have in an "Accessibility mode" for PSReadLine beyond the buffer re-draw issue.
I think we need:
- Ask the users who are asking for this support: what features in PSReadLine they would like to have when working with a screen reader.
- Then we go through the asked features and figure out whether each of them makes sense from the user perspective, and whether it's feasible from the implementation perspective (without depending on erasing/re-rendering).
Hey guys, I am a screenreader user (NVDA) and would be happy if there would be support for screenreaders. It would be nice, if the Completition feature in menu style works and the history browsing.
As a totally blind programmer learning PowerShell and coming from a BASH background, I believe making PSReadLine accessible would significantly enhance the command-line experience for screen reader users. Here are the key features I'd like to see made accessible:
-
Syntax error notifications: Audible or screen reader-friendly notifications of syntax errors as we type.
-
Customizable keybindings: Ability to set and use custom keyboard shortcuts that work well with screen readers.
-
BASH-style completion and history search: Accessible ways to navigate and select from completion options and search command history (e.g., CTRL-R functionality).
-
Undo/redo functionality: Accessible commands to undo and redo actions with clear feedback.
-
Automatic saving and cross-session history: Ability to access and navigate through command history from previous sessions.
-
Autocompletion and command autosuggestion: Screen reader-friendly presentation of autocomplete options and command suggestions.
-
Predictive IntelliSense: Accessible way to view and select from predictive suggestions.
-
Enhanced copy/cut/paste functionality: Improved clipboard operations with clear feedback for screen reader users.
-
Parameter and argument viewing: Accessible method to explore available parameters and arguments for commands.
-
Syntax highlighting: While visual, having an audible or tactile way to convey syntax information would be valuable.
Implementing these features in an accessible manner would greatly improve the PowerShell experience for visually impaired users, bringing it closer to the rich command-line environments we've experienced in other systems like Linux with BASH.
I'm happy to provide more detailed feedback on specific implementations or to test accessibility features as they're developed.
My reason for ps_read_line accessibility is the ability to enable shell integration in VSCode using PowerShell. Right now, even if the checkbox is checked to enable it, shell integration is disabled due to ps_read_line. That, plus modern features like autocomplete suggestions and the like.
The start of this support is now well on its way, see the PR for what's known to be supported/unsupported.
Some responses to @Lanie-Carmelo's list.
- Syntax error notifications: Audible or screen reader-friendly notifications of syntax errors as we type.
Perhaps we should ding the terminal when _parseErrors is true after parsing input? It could be (literally) noisy though, I wouldn't want it to be dinging after every character until the symbol is completed.
- Customizable keybindings: Ability to set and use custom keyboard shortcuts that work well with screen readers.
Keybindings can already be customized in PSReadLine. I'd like to know what other support would be helpful.
- BASH-style completion and history search: Accessible ways to navigate and select from completion options and search command history (e.g., CTRL-R functionality).
The PR supports incremental history search (with the status prompt). Caveat: it can be noisy since it necessarily has to render the whole buffer when the presented history item changes, including the status prompt (and search text). But what it's reading is almost always going to be relevant. Inside VS Code, Ctrl+R is rebound to a much more accessible panel they've implemented via shell integration.
The PR also supports completions e.g. MenuComplete/tab. Inline predictions are not supported (can't be done without being too noisy).
- Undo/redo functionality: Accessible commands to undo and redo actions with clear feedback.
The extant undo/redo works as-is, I'd like to know what we could do to ensure there's "clear feedback." Perhaps again ding when these commands are executed?
- Automatic saving and cross-session history: Ability to access and navigate through command history from previous sessions.
That should just work as PSReadLine already supports history, and the PR supports both incremental history search and up/down history scrolling. I'll note that I specifically disabled the differential rendering when displaying a history item. While testing I realized that if you have history items with common prefixes, e.g. "git status" and "git commit" that scrolling from one to the other was confusing if the common prefix "git" wasn't also rendered. So there's a specific check for this behavior such that the whole history item is redrawn.
- Autocompletion and command autosuggestion: Screen reader-friendly presentation of autocomplete options and command suggestions.
So, it works (including the yes/no prompt to display N+ items), but I can't claim it to be specifically screen reader friendly as it's going to read everything displayed. I think this is where VS Code's shell integration can make a lot more improvement, which this PR enables.
- Predictive IntelliSense: Accessible way to view and select from predictive suggestions.
This one is specifically not supported. Any text added to the buffer after the cursor must, at this point, be deleted and redrawn when any change at the cursor is made. So inline predictions very specifically will cause a redraw for every keystroke, and there's not currently a way around this with just the terminal. Perhaps VS Code's shell integration can make this work.
- Enhanced copy/cut/paste functionality: Improved clipboard operations with clear feedback for screen reader users.
There's a theme here on how to add clear feedback to some existing operations. I don't really like suggesting dinging the terminal for all these things. Maybe that'll be a marginal improvement, but there's definitely a conversation to be had here.
- Parameter and argument viewing: Accessible method to explore available parameters and arguments for commands.
Same as above.
- Syntax highlighting: While visual, having an audible or tactile way to convey syntax information would be valuable.
With the way syntax highlighting is currently implemented, it is 90% of the root cause of the screen reader being rendered useless for PSReadLine. This is the whole redrawing issue: it's only after enough input is received that it can be syntactically parsed, and then given that information, the (already drawn) input needs to be edited to have the escape sequences that colorize it inserted, which redraws and thus causes the screen reader to repeat what's already been written. There isn't a way around this until there is a protocol we can use to essentially pause the screen reader from reading, so we can redraw, and then resume, and that doesn't address what this would look like audibly or tactilely. The chicken-egg problem of needing to parse complete input to understand the syntax is a bit difficult to workaround.
