Incoming text is periodically not read by screen readers #14834

Closed
opened 2026-01-31 04:20:42 +00:00 by claunia · 26 comments
Owner

Originally created by @Neurrone on GitHub (Aug 10, 2021).

Originally assigned to: @carlos-zamora on GitHub.

Windows Terminal version (or Windows build number)

1.9.1942.0

Other Software

Screen readers tested: Narrator, NVDA alpha-23553,3c29f9ad, observed while running in WSL2 Ubuntu in case that is somehow relevant

Steps to reproduce

/CC @codeofdusk per our previous discussion about this, @carlos-zamora

This appears to happen Intermittently, but for me I can fairly reliably reproduce this when I'm using Docker to run the postgres cli tool to interact with a Postgres database.

docker run -it postgres:13.3 psql -h db_host -U db_user

I would execute the following commands:

  1. \c <database> to use a database
  2. \d to describe a table

    Expected Behavior

    Incoming text continues to be reliably read by both NVDA and Narrator

    Actual Behavior

    Even though new text would be written on-screen, both NVDA and Narrator would fail to read it. I am able to use object navigation to manually go upwards in NVDA to read the newly written text, but that's not a practical solution.

    The fact that Narrator is also vulnerable to this makes me suspect a bug in Terminal itself.

    Restarting either screen reader does not fix it.

Originally created by @Neurrone on GitHub (Aug 10, 2021). Originally assigned to: @carlos-zamora on GitHub. ### Windows Terminal version (or Windows build number) 1.9.1942.0 ### Other Software Screen readers tested: Narrator, NVDA alpha-23553,3c29f9ad, observed while running in WSL2 Ubuntu in case that is somehow relevant ### Steps to reproduce /CC @codeofdusk per our previous discussion about this, @carlos-zamora This appears to happen Intermittently, but for me I can fairly reliably reproduce this when I'm using Docker to run the postgres cli tool to interact with a Postgres database. ```sh docker run -it postgres:13.3 psql -h db_host -U db_user ``` I would execute the following commands: 1. `\c <database>` to use a database 2. \d <table> to describe a table ### Expected Behavior Incoming text continues to be reliably read by both NVDA and Narrator ### Actual Behavior Even though new text would be written on-screen, both NVDA and Narrator would fail to read it. I am able to use object navigation to manually go upwards in NVDA to read the newly written text, but that's not a practical solution. The fact that Narrator is also vulnerable to this makes me suspect a bug in Terminal itself. Restarting either screen reader does not fix it.
Author
Owner

@zadjii-msft commented on GitHub (Aug 10, 2021):

I'm not sure this isn't already tracked somewhere (probably in https://github.com/microsoft/terminal/issues?q=is%3Aopen+is%3Aissue+label%3AArea-Accessibility), but I'll tag it up assuming it isn't. Thanks!

@zadjii-msft commented on GitHub (Aug 10, 2021): I'm not sure this isn't already tracked somewhere (probably in https://github.com/microsoft/terminal/issues?q=is%3Aopen+is%3Aissue+label%3AArea-Accessibility), but I'll tag it up assuming it isn't. Thanks!
Author
Owner

@codeofdusk commented on GitHub (Aug 10, 2021):

Nope, this looks like a new bug (I asked him to file here).

@codeofdusk commented on GitHub (Aug 10, 2021): Nope, this looks like a new bug (I asked him to file here).
Author
Owner

@carlos-zamora commented on GitHub (Aug 10, 2021):

Curious, does this repro in conhost?

@carlos-zamora commented on GitHub (Aug 10, 2021): Curious, does this repro in conhost?
Author
Owner

@Neurrone commented on GitHub (Aug 10, 2021):

I believe not from memory but let me test this and I'll double confirm by the end of the week.

@Neurrone commented on GitHub (Aug 10, 2021): I believe not from memory but let me test this and I'll double confirm by the end of the week.
Author
Owner

@Neurrone commented on GitHub (Aug 11, 2021):

Confirmed that its only affecting terminal, and I was able to reproduce it 100% of the time.

  1. Set up an instance of postgres (I did it via docker on my development machine)
  2. Connect to Postgres:
docker run -it --rm postgres:13.3 psql -h db -U postgres
Password for user postgres:                                                                                                          
psql (13.3 (Debian 13.3-1.pgdg100+1), server 12.6 (Debian 12.6-1.pgdg100+1))                                                         
Type "help" for help.                                                                                                                
                                                                                                                                     
postgres=# \l                                                                                                                        
                                  List of databases                                                                                  
     Name     |  Owner   | Encoding |  Collate   |   Ctype    |   Access privileges                                                  
--------------+----------+----------+------------+------------+-----------------------                                               
 applications | postgres | UTF8     | en_US.utf8 | en_US.utf8 |                                                                      
 postgres     | postgres | UTF8     | en_US.utf8 | en_US.utf8 |                                                                      
 template0    | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +                                               
              |          |          |            |            | postgres=CTc/postgres                                                
 template1    | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +                                               
              |          |          |            |            | postgres=CTc/postgres                                                
(4 rows)                                                                                                                             
                                                                                                                                     
postgres=# \c applications                                                                                                           
psql (13.3 (Debian 13.3-1.pgdg100+1), server 12.6 (Debian 12.6-1.pgdg100+1))                                                         
You are now connected to database "applications" as user "postgres".                                                                 

All output just before the command \c applications to connect to the applications database reads fine. All new incoming text after that refuses to read, even if I exit the docker container.

@Neurrone commented on GitHub (Aug 11, 2021): Confirmed that its only affecting terminal, and I was able to reproduce it 100% of the time. 1. Set up an instance of postgres (I did it via docker on my development machine) 2. Connect to Postgres: ``` docker run -it --rm postgres:13.3 psql -h db -U postgres Password for user postgres: psql (13.3 (Debian 13.3-1.pgdg100+1), server 12.6 (Debian 12.6-1.pgdg100+1)) Type "help" for help. postgres=# \l List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges --------------+----------+----------+------------+------------+----------------------- applications | postgres | UTF8 | en_US.utf8 | en_US.utf8 | postgres | postgres | UTF8 | en_US.utf8 | en_US.utf8 | template0 | postgres | UTF8 | en_US.utf8 | en_US.utf8 | =c/postgres + | | | | | postgres=CTc/postgres template1 | postgres | UTF8 | en_US.utf8 | en_US.utf8 | =c/postgres + | | | | | postgres=CTc/postgres (4 rows) postgres=# \c applications psql (13.3 (Debian 13.3-1.pgdg100+1), server 12.6 (Debian 12.6-1.pgdg100+1)) You are now connected to database "applications" as user "postgres". ``` All output just before the command `\c applications` to connect to the applications database reads fine. All new incoming text after that refuses to read, even if I exit the docker container.
Author
Owner

@Neurrone commented on GitHub (Oct 8, 2021):

Any news on this?

This is something that I run into every day, and can reproduce easily.

@Neurrone commented on GitHub (Oct 8, 2021): Any news on this? This is something that I run into every day, and can reproduce easily.
Author
Owner

@zadjii-msft commented on GitHub (Oct 8, 2021):

Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button?
image
That way you'll be notified of any updates to this thread.

@zadjii-msft commented on GitHub (Oct 8, 2021): Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button? ![image](https://user-images.githubusercontent.com/18356694/91237459-5cbb0c80-e700-11ea-9347-b9b1ec2813b1.png) That way you'll be notified of any updates to this thread.
Author
Owner

@codeofdusk commented on GitHub (Nov 22, 2021):

Received another report of this as nvaccess/nvda#13075, but I personally can't repro. Cc @carlos-zamora.

@codeofdusk commented on GitHub (Nov 22, 2021): Received another report of this as nvaccess/nvda#13075, but I personally can't repro. Cc @carlos-zamora.
Author
Owner

@Neurrone commented on GitHub (Jan 20, 2022):

Wondering if there's anything I can do to help with reproduction of this bug? As I am able to reproduce this daily and it is a massive pain when output stops being read.

@Neurrone commented on GitHub (Jan 20, 2022): Wondering if there's anything I can do to help with reproduction of this bug? As I am able to reproduce this daily and it is a massive pain when output stops being read.
Author
Owner

@zadjii-msft commented on GitHub (Jan 20, 2022):

If you'd like to take a look at the code yourself and investigate, we'd love a PR ☺️ Otherwise at this point it's just waiting for us to have time to come back to this and actually look into it ourselves. Hopefully sometime in the next 6 mos?

@zadjii-msft commented on GitHub (Jan 20, 2022): If you'd like to take a look at the code yourself and investigate, we'd love a PR ☺️ Otherwise at this point it's just waiting for us to have time to come back to this and actually look into it ourselves. Hopefully sometime in the next 6 mos?
Author
Owner

@codeofdusk commented on GitHub (Jan 20, 2022):

I suspect that the impending switch to UIA notifications will help with this. CC @carlos-zamora @DHowett

@codeofdusk commented on GitHub (Jan 20, 2022): I suspect that the impending switch to UIA notifications will help with this. CC @carlos-zamora @DHowett
Author
Owner

@zadjii-msft commented on GitHub (Mar 10, 2022):

I'm tossing this to @carlos-zamora if he gets a free moment to confirm that this is actually fixed by #12358.

@zadjii-msft commented on GitHub (Mar 10, 2022): I'm tossing this to @carlos-zamora if he gets a free moment to confirm that this is actually fixed by #12358.
Author
Owner

@zadjii-msft commented on GitHub (Mar 17, 2022):

We believe that this should be fixed by #12358 (which should ship in the next hotfix version of the Terminal soontm). We have not been able to confirm however.

@zadjii-msft commented on GitHub (Mar 17, 2022): We believe that this should be fixed by #12358 (which should ship in the next hotfix version of the Terminal soon<sup>tm</sup>). We have _not_ been able to confirm however.
Author
Owner

@codeofdusk commented on GitHub (Mar 17, 2022):

We believe that this should be fixed by #12358

In theory yes, but in practice no. NVDA doesn't yet leverage UIA notifications (see PR nvaccess/nvda#13261) because I want to think carefully about how that should work, and I haven't yet had the cycles to work further on it.

@codeofdusk commented on GitHub (Mar 17, 2022): > We believe that this should be fixed by #12358 In theory yes, but in practice no. NVDA doesn't yet leverage UIA notifications (see PR nvaccess/nvda#13261) because I want to think carefully about how that should work, and I haven't yet had the cycles to work further on it.
Author
Owner

@zadjii-msft commented on GitHub (Mar 18, 2022):

Okay thanks for the clarification. Is there an upstream issue on NVDA that we can close this as a duplicate of? (for housekeeping purposes)

@zadjii-msft commented on GitHub (Mar 18, 2022): Okay thanks for the clarification. Is there an upstream issue on NVDA that we can close this as a duplicate of? (for housekeeping purposes)
Author
Owner

@carlos-zamora commented on GitHub (Apr 19, 2022):

/dup https://github.com/nvaccess/nvda/pull/13261

@carlos-zamora commented on GitHub (Apr 19, 2022): /dup https://github.com/nvaccess/nvda/pull/13261
Author
Owner

@ghost commented on GitHub (Apr 19, 2022):

Hi! We've identified this issue as a duplicate of one that exists on somebody else's Issue Tracker. Please make sure you subscribe to the referenced external issue for future updates. Thanks for your report!

@ghost commented on GitHub (Apr 19, 2022): Hi! We've identified this issue as a duplicate of one that exists on somebody else's Issue Tracker. Please make sure you subscribe to the referenced external issue for future updates. Thanks for your report!
Author
Owner

@Neurrone commented on GitHub (Apr 20, 2022):

I've seen this bug with Narrator, so I believe this is actually a Terminal issue, not NVDA specific.

@Neurrone commented on GitHub (Apr 20, 2022): I've seen this bug with Narrator, so I believe this is actually a Terminal issue, not NVDA specific.
Author
Owner

@DHowett commented on GitHub (Apr 20, 2022):

@Neurrone Have you seen this issue with Narrator and Windows Terminal 1.12.10730 or higher? That is the first version that shipped with #12358, which specifically addresses this issue for Narrator.

@DHowett commented on GitHub (Apr 20, 2022): @Neurrone Have you seen this issue with Narrator and Windows Terminal 1.12.10730 or higher? That is the first version that shipped with #12358, which specifically addresses this issue for Narrator.
Author
Owner

@carlos-zamora commented on GitHub (Dec 12, 2022):

@codeofdusk told me there's been a lot of reports for this one and he has a consistent repro. Reopening it and assigning it to the current milestone.

@carlos-zamora commented on GitHub (Dec 12, 2022): @codeofdusk told me there's been a lot of reports for this one and he has a consistent repro. Reopening it and assigning it to the current milestone.
Author
Owner

@codeofdusk commented on GitHub (Dec 13, 2022):

I discussed this with @simon818. We're both able to consistently repro this by outputting enough text to fill the screen:

  1. Start wt.
  2. Echo 10,000 "a" characters.
  3. Then, echo hello.

Expected: a textChange event is received, NVDA diffs the screen and says "hello".

Actual: After the screen is filled, textChange (and consequently autoread) stops.

UIA notifications are unaffected (or at least not as severely affected).

@codeofdusk commented on GitHub (Dec 13, 2022): I discussed this with @simon818. We're both able to consistently repro this by outputting enough text to fill the screen: 1. Start `wt`. 2. Echo 10,000 "a" characters. 3. Then, `echo hello`. Expected: a `textChange` event is received, NVDA diffs the screen and says "hello". Actual: After the screen is filled, `textChange` (and consequently autoread) stops. UIA notifications are unaffected (or at least not as severely affected).
Author
Owner

@GabrieleBattaglia commented on GitHub (Dec 13, 2022):

Hi I experiment this bug all the days as I work a lot with terminal. I had to switch back to the old and stupid cmd to not being bothered by this severe issue.
My question is the following: beside this tracker which is opened since 1 and half year, is there some schedule to take care of the problem. Is there enough data gathered to study for a solution plan? Can I allow myself to hope to see it fixed and in how much time?
Thanks.
PS: I don't want to complain,it's just to ask.

@GabrieleBattaglia commented on GitHub (Dec 13, 2022): Hi I experiment this bug all the days as I work a lot with terminal. I had to switch back to the old and stupid cmd to not being bothered by this severe issue. My question is the following: beside this tracker which is opened since 1 and half year, is there some schedule to take care of the problem. Is there enough data gathered to study for a solution plan? Can I allow myself to hope to see it fixed and in how much time? Thanks. PS: I don't want to complain,it's just to ask.
Author
Owner

@zadjii-msft commented on GitHub (Dec 13, 2022):

Well, now that we've got a consistent repro, we'll try and get this in for 1.17, due out sometime in January. This thread has a lot of back and forth on the root cause.

I reckon, based on the last post, that this is due to the notifications not being sent when the buffer circles (the viewport's not changing in this case, but it seems like it is, and it should send a notification).

@zadjii-msft commented on GitHub (Dec 13, 2022): Well, now that we've got a consistent repro, we'll try and get this in for 1.17, due out sometime in January. This thread has a lot of back and forth on the root cause. I reckon, based on the last post, that this is due to the notifications not being sent when the buffer circles (the viewport's not changing in this case, but it _seems_ like it is, and it _should_ send a notification).
Author
Owner

@carlos-zamora commented on GitHub (Jan 20, 2023):

Closing as no repro. @codeofdusk and I chatted about this. Funny enough, the repro steps he provided were posted the day before an update, so there's a chance that the update fixed it.

If we get more reports of this, we'll open it up again.

@carlos-zamora commented on GitHub (Jan 20, 2023): Closing as no repro. @codeofdusk and I chatted about this. Funny enough, the repro steps he provided were posted the day before an update, so there's a chance that the update fixed it. If we get more reports of this, we'll open it up again.
Author
Owner

@pawin35 commented on GitHub (Jan 20, 2023):

I can confirm that the issue still persists as of the Windows Terminal preview version 1.16.3464.0. When the viewport of the terminal is fully filled (I do this by running the "dir" command in a large folder multiple times), the subsequent command that has an output (such as "echo a") will not produce the UIA_textchange event, and therefore cannot be detected and autoread by the screen reader. Interestingly, when I type individual characters such as "e", "c", "h", "o", "space", "quote", "a", and "quote", all of them produce the correct textchange event. However, once I press enter, there is no textchange event emitted from the TermControl, only a UIA_notification is produced, which the NVDA screen reader currently ignores. My environment is as follows: NVDA 2022.4 fresh install, and Windows 11 Pro version 22H2 (OS Build 22621.1105).

@pawin35 commented on GitHub (Jan 20, 2023): I can confirm that the issue still persists as of the Windows Terminal preview version 1.16.3464.0. When the viewport of the terminal is fully filled (I do this by running the "dir" command in a large folder multiple times), the subsequent command that has an output (such as "echo a") will not produce the UIA_textchange event, and therefore cannot be detected and autoread by the screen reader. Interestingly, when I type individual characters such as "e", "c", "h", "o", "space", "quote", "a", and "quote", all of them produce the correct textchange event. However, once I press enter, there is no textchange event emitted from the TermControl, only a UIA_notification is produced, which the NVDA screen reader currently ignores. My environment is as follows: NVDA 2022.4 fresh install, and Windows 11 Pro version 22H2 (OS Build 22621.1105).
Author
Owner

@pawin35 commented on GitHub (Jan 20, 2023):

@carlos-zamora I'm not sure if this counts as a partial reproduction, but I've attached the debug log of NVDA in case it might be useful.
The first log shows the behavior when typing echo "a" on a freshly opened terminal, i.e. a blank viewport (expected behavior).
first_case.txt
The second log shows the behavior when typing echo "a" on a full viewport (typing dir a bunch of times) (actual behavior).
second_case.txt
Observe that in the second case, the textchange event is not emitted after pressing enter.

@pawin35 commented on GitHub (Jan 20, 2023): @carlos-zamora I'm not sure if this counts as a partial reproduction, but I've attached the debug log of NVDA in case it might be useful. The first log shows the behavior when typing `echo "a"` on a freshly opened terminal, i.e. a blank viewport (expected behavior). [first_case.txt](https://github.com/microsoft/terminal/files/10470392/first_case.txt) The second log shows the behavior when typing `echo "a"` on a full viewport (typing `dir` a bunch of times) (actual behavior). [second_case.txt](https://github.com/microsoft/terminal/files/10470393/second_case.txt) Observe that in the second case, the textchange event is not emitted after pressing enter.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#14834