Unable to use applications that hook the arrow keys using Windows Console Host. #18092

@trypsynth commented on GitHub (Aug 4, 2022):

I can now confirm that its a screen reader only problem. The cursor moves, but NVDA and Narrator just don't read it

@trypsynth commented on GitHub (Aug 4, 2022): I can now confirm that its a screen reader only problem. The cursor moves, but NVDA and Narrator just don't read it

claunia commented

@zadjii-msft commented on GitHub (Aug 4, 2022):

@carlos-zamora You know if we've got this one on the backlog? You're usually faster at searching the a11y threads than me ☺️

@zadjii-msft commented on GitHub (Aug 4, 2022): @carlos-zamora You know if we've got this one on the backlog? You're usually faster at searching the a11y threads than me ☺️

claunia commented

@carlos-zamora commented on GitHub (Aug 4, 2022):

Doesn't sound familiar from the backlog. This sounds pretty sever though.
@TheQuinbox a few questions for you:

What shell are you using? It sounds like you're using PowerShell, but can you tell me the version? FYI "PowerShell 7.3.0-preview.6" adds suggested text as you type. I still don't get the "blank" behavior, but idk if that's related?
When you say "attempt to arrow", what direction are you going in? up/down to select the previous/next command? Or left, right to move the cursor?
What GH command are you executing exactly? I can't find any that hook the arrow keys. Upon execution (at least the ones I use), the command just outputs text that is then read by the screen reader, as expected.

I can't get a repro, so I'm hoping some more details can help. Thanks!

@carlos-zamora commented on GitHub (Aug 4, 2022): Doesn't sound familiar from the backlog. This sounds pretty sever though. @TheQuinbox a few questions for you: - What shell are you using? It sounds like you're using PowerShell, but can you tell me the version? FYI "PowerShell 7.3.0-preview.6" adds suggested text as you type. I still don't get the "blank" behavior, but idk if that's related? - When you say "attempt to arrow", what direction are you going in? up/down to select the previous/next command? Or left, right to move the cursor? - What GH command are you executing exactly? I can't find any that hook the arrow keys. Upon execution (at least the ones I use), the command just outputs text that is then read by the screen reader, as expected. I can't get a repro, so I'm hoping some more details can help. Thanks!

claunia commented

@trypsynth commented on GitHub (Aug 4, 2022):

Hi @carlos-zamora,
I'm using Command Prompt, but I just tested, and it also happens with PowerShell.
I'm using the up and down arrow keys to move between options. If using NVDA's review cursor, I can tell what option is selected, but it takes significantly more time.
I'm running:

$ gh pr create

when on a branch with uncommitted changes. I'm then brought to a wizard that asks me to select an option.

Its probably worth mentioning that I've also tested this in standalone CMD.exe and PowerShell.exe shells and it doesn't happen.

If still unable to reproduce, would an audio demonstration possibly help?

Thanks so much for looking into this! :)

@trypsynth commented on GitHub (Aug 4, 2022): Hi @carlos-zamora, I'm using Command Prompt, but I just tested, and it also happens with PowerShell. I'm using the up and down arrow keys to move between options. If using NVDA's review cursor, I can tell what option is selected, but it takes significantly more time. I'm running: ```shell $ gh pr create ``` when on a branch with uncommitted changes. I'm then brought to a wizard that asks me to select an option. Its probably worth mentioning that I've also tested this in standalone CMD.exe and PowerShell.exe shells and it doesn't happen. If still unable to reproduce, would an audio demonstration possibly help? Thanks so much for looking into this! :)

claunia commented

@carlos-zamora commented on GitHub (Aug 4, 2022):

Awesome. Got it! Thanks!

For visual users, this is what the UI looks like:

In this case, the text reads:

D:\Projects\terminal>gh pr create
? Where should we push the 'dev/cazamor/test' branch?  [Use arrows to move, type to filter]
  microsoft/terminal
> Create a fork of microsoft/terminal
  Skip pushing the branch
  Cancel

The key thing to see here is the ">". Pressing up and down "moves" that symbol.

Here's the tricky party though, when up/down is pressed, the screen reader reads the entire output again, suggesting that gh.exe is actually deleting and re-rendering the entire output again with the ">" in the correct place.

Now, as for a fix, I'm a bit stumped. I'll throw the "Needs-Discussion" tag so that we discuss this at an upcoming sync. Fair warning, I'm about to head out on vacation for a bit, so it'll probably be a while before I get back to you on this one. Maybe 2 weeks? Don't worry though, as long as that "Needs-Discussion" tag is on the issue, we'll get to it (we go over as many as we can when we meet up at our weekly sync meeting)

@carlos-zamora commented on GitHub (Aug 4, 2022): Awesome. Got it! Thanks! For visual users, this is what the UI looks like: <img width="655" alt="image of command output" src="https://user-images.githubusercontent.com/11050425/182952059-a86d0f5b-de3f-48ac-8004-f77a1c1ff549.png"> In this case, the text reads: ``` D:\Projects\terminal>gh pr create ? Where should we push the 'dev/cazamor/test' branch? [Use arrows to move, type to filter] microsoft/terminal > Create a fork of microsoft/terminal Skip pushing the branch Cancel ``` The key thing to see here is the ">". Pressing up and down "moves" that symbol. Here's the tricky party though, when up/down is pressed, the screen reader reads the entire output again, suggesting that gh.exe is actually deleting and re-rendering the entire output again with the ">" in the correct place. Now, as for a fix, I'm a bit stumped. I'll throw the "Needs-Discussion" tag so that we discuss this at an upcoming sync. Fair warning, I'm about to head out on vacation for a bit, so it'll probably be a while before I get back to you on this one. Maybe 2 weeks? Don't worry though, as long as that "Needs-Discussion" tag is on the issue, we'll get to it (we go over as many as we can when we meet up at our weekly sync meeting)

claunia commented

@trypsynth commented on GitHub (Aug 4, 2022):

Awesome, sounds great! I have honestly no idea how Terminal renders, but I do remember hearing that it uses the GPU. Maybe that's playing a part? As stated previously this doesn't happen anywhere else.

Thanks for looking into this! :)

@trypsynth commented on GitHub (Aug 4, 2022): Awesome, sounds great! I have honestly no idea how Terminal renders, but I do remember hearing that it uses the GPU. Maybe that's playing a part? As stated previously this doesn't happen anywhere else. Thanks for looking into this! :)

claunia commented

@trypsynth commented on GitHub (Oct 19, 2022):

Hi,
have there been any updates on this issue? Am still fully able to reproduce on Windows 11 22h2 (build 22000.198), with Windows Terminal 1.15.2875.0.
Thanks!

@trypsynth commented on GitHub (Oct 19, 2022): Hi, have there been any updates on this issue? Am still fully able to reproduce on Windows 11 22h2 (build 22000.198), with Windows Terminal 1.15.2875.0. Thanks!

claunia commented

@carlos-zamora commented on GitHub (Oct 21, 2022):

Hi @TheQuinbox. Sorry I didn't get back to you! Yeah, so like I said in my comment above, I don't think there's a quick-n-easy fix for this. gh.exe is rewriting the entire prompt every time, resulting in the screen readers thinking either (1) the entire prompt is "new content" that needs to be reread, or (2) nothing changed because the new content is largely similar to the old content.

You could file a bug on NVDA/Narrator to have better handling for this kind of scenario. That might be the quickest way forward to see change here.

Outside of that, the best idea I've come up with is to develop a system for which command line applications can explicitly tell screen readers what to read out. However, this involves changes on our end and on the app's end (in this case, gh.exe), and that'll take months to get done.

Regardless, I'm sorry to say that implementing a solution here is going to take a long time. I'll keep this thread in the loop as new updates develop.

@carlos-zamora commented on GitHub (Oct 21, 2022): Hi @TheQuinbox. Sorry I didn't get back to you! Yeah, so like I said in my comment above, I don't think there's a quick-n-easy fix for this. `gh.exe` is rewriting the entire prompt every time, resulting in the screen readers thinking either (1) the entire prompt is "new content" that needs to be reread, or (2) nothing changed because the new content is largely similar to the old content. You could file a bug on NVDA/Narrator to have better handling for this kind of scenario. That might be the quickest way forward to see change here. Outside of that, the best idea I've come up with is to develop a system for which command line applications can explicitly tell screen readers what to read out. However, this involves changes on our end and on the app's end (in this case, gh.exe), and that'll take months to get done. Regardless, I'm sorry to say that implementing a solution here is going to take a long time. I'll keep this thread in the loop as new updates develop.

claunia commented

@zadjii-msft commented on GitHub (Oct 26, 2022):

x-linking:

Control Screen Reader from Applications.
- This is a good example of how we might want to enable this in the future. It would require apps to build in support for this manually, but diff'ing or trying to do heuristics is probably a non-starter
https://github.com/microsoft/winget-cli/issues/161
- We've talked with the winget folks and they're very interested in this.

@zadjii-msft commented on GitHub (Oct 26, 2022): x-linking: * [Control Screen Reader from Applications](https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/18). * This is a good example of how we might want to enable this in the future. It would require apps to build in support for this manually, but diff'ing or trying to do heuristics is probably a non-starter * https://github.com/microsoft/winget-cli/issues/161 * We've talked with the winget folks and they're very interested in this.

claunia commented

@Adriani90 commented on GitHub (Dec 7, 2024):

Any updates on this issue? Is it still occuring with screen readers?

@Adriani90 commented on GitHub (Dec 7, 2024): Any updates on this issue? Is it still occuring with screen readers?

claunia commented

@seanbudd commented on GitHub (Sep 12, 2025):

Any updates on this issue?

@seanbudd commented on GitHub (Sep 12, 2025): Any updates on this issue?

claunia commented