Acessibility: create an output painel for screen readers used by people with visual impairment

[geazi-anc]

Description of the new feature/enhancement

Currently, Windows Terminal is not fully accessibble for people with visual impairment that use screen readers to navigate this tool.

The main reason is because the output of a command is not easily shown when an input is typed. To "solve" this problem, you need to copy all the text from terminal using CTRL + A and after CTRL + C and after CTRL + V shortcut into a text editor to see and navigate the output.

Therefore, a new feature to create a output painel woud solve this problem of people with visual impairment. The Visual Studio Code Terminal is a good example of an accessiblity terminal. I think to copy the features from it would be a good starting point.

If you have any question about this feature, please contact me!

[carlos-zamora]

Thanks for the feature request! I actually really like this idea and it's cool to see that VS Code's terminal is already doing that. Added it to the backlog.

The main reason is because the output of a command is not easily shown when an input is typed.

Curious what you mean by this. Could you elaborate a bit please?

[geazi-anc]

Thanks for the feature request! I actually really like this idea and it's cool to see that VS Code's terminal is already doing that. Added it to the backlog.

The main reason is because the output of a command is not easily shown when an input is typed.

Curious what you mean by this. Could you elaborate a bit please?

Thank you so much! Let me explain a bit more about your question:

When you type a command, for example sudo apt update, the output is shown for screen readers, and it reads it for people with visual impairment. When the output is brief, ok. The screen readers show the output for us.

However, when the output is long, how I said using sudo apt update, is shown a lot of information at the same time, so we pause the reading of screen readers. After that, we navigate thhe output to know the result of this command. For this, we need to copy the all output from terminal and pass it into a text editor. It's an inconvenient and difficult way to use terminal, specialy in our daily work that use Windows Terminal with WSL to code. Therefore, this feature is very important for people with visual impairment :).

If you have any further questions, please let me know.

[zadjii-msft]

After that, we navigate thhe output to know the result of this command. For this, we need to copy the all output from terminal and pass it into a text editor

Out of curiosity, why copy to a text editor? The Terminal has implemented (what I believe are) most UIA patterns that are relevant for reading text from the Terminal buffer for a while now. Is there something about the Terminal's UIA implementation that's lacking to the extent that it's easier to just use a text editor?

---

We're still planning on doing this regardless

[geazi-anc]

After that, we navigate thhe output to know the result of this command. For this, we need to copy the all output from terminal and pass it into a text editor

Out of curiosity, why copy to a text editor? The Terminal has implemented (what I believe are) most UIA patterns that are relevant for reading text from the Terminal buffer for a while now. Is there something about the Terminal's UIA implementation that's lacking to the extent that it's easier to just use a text editor?

We're still planning on doing this regardless

How I said, copy output from terminal and pass it into a text editor is necessary to navigate through this using a screen reader. Again, when we type a command in terminal, the output is shown for us. However, if output is too long, is more convenient pause the reading of screen reader and navigate with arrow keys to see what is really we want. But Windows Terminal hasn't an output painel to make it easily. For this reason the copy and pass process is necessary.

[carlos-zamora]

Spoke with @codeofdusk to pick his brain a bit. Here's some notes:

• this kind of feature seems to be similar to Tera Term. He said to play with that terminal a bit to get an idea.
• the concept seems to be like there's a basic Text Box for the input buffer (so, stuff like PSReadline is disabled, but Enter is still interpreted as "send command"). And the full output of the terminal is copied over to a read-only text box. Sounds like this helps remove any keybindings from the CLI app or attached terminal, so it gives you a clean experience.
• How does this work with "less" and other alt-buffer scenarios:
  • the new content gets appended to the read-only text box. So, yes, something like "clear" won't work well haha. But something like "less" (specifically when "space" is pressed) works ok in that the new content is appended.

Honestly, with that information, I don't feel like we'd need a spec anymore. This should be trivial if we have #997 around (and I think that would be a cool way to make this look better too).

[zadjii-msft]

https://github.com/microsoft/terminal/pull/new/dev/migrie/f/16005-a11y-pane

[zadjii-msft]

@Tyriar This is the thread I was talking about

[Danstiv]

@geazi-anc, screen readers, as far as I know, allows to read the output line by line and character by character without copying it. What screen reader are you using?
In the case of NVDA, you can use numpad7 and numpad9 to move through lines, numpad4 and numpad6 - through words, numpad1 and numpad3 - through characters.

[geazi-anc]

@geazi-anc, screen readers, as far as I know, allows to read the output line by line and character by character without copying it. What screen reader are you using? In the case of NVDA, you can use numpad7 and numpad9 to move through lines, numpad4 and numpad6 - through words, numpad1 and numpad3 - through characters.

@Danstiv yes, screen readers allow to read texts without copy them. However, it's not possible in Windows Terminal. I use NVDA, and these key shortcuts doesn't work as well. Using these key shortcuts, the screen reader reads the content of desktop window instead of terminal.

[Danstiv]

the screen reader reads the content of desktop window instead of terminal.

I cannot reproduce this.

Probably navigator object does not follow focus.

That setting could be configured in NVDA menu -> Preferences -> settings -> Review Cursor.

There is a "Follow system focus" checkbox that should be checked.

Next, in the terminal window, you need to switch to object review mode (nvda+numpad1), after which the method of navigating through the text that I described should start working.

Sorry that I'm teaching you how to use NVDA, you probably already know this, but your problem seemed very strange to me, and I'm trying to figure it out and help.

[geazi-anc]

There is a "Follow system focus" checkbox that should be checked.

Thank you for your help! After this configuration I was able to read the terminal content using the indicated shortcuts.

However, I must say, navigation in this mode is not very intuitive. If navigation were using the arrow keys on the keyboard it would be more natural. This would be possible, as I said, through an output panel in Terminal, as with Visual Studio Code.

Otherwise, thank you in advance!