JAWS reads the entire frame on every key in nano over SSH #19101

Closed
opened 2026-01-31 06:33:48 +00:00 by claunia · 3 comments
Owner

Originally created by @adns44 on GitHub (Dec 19, 2022).

Originally assigned to: @carlos-zamora on GitHub.

Windows Terminal version

1.15.221212005

Windows build number

10.0.19045.2364

Other Software

JAWS For Windows 2023

Steps to reproduce

Open an Linux SSH host with OpenSSH client and try to use nano to write or edit any text with multiple pines

Expected Behavior

JAWS reads the correct line by navigating up and down and don't start reading from the top of the window when I edit the text in nano.

Seems that the problem relating to rendering but I'm not an expert in it.

Actual Behavior

JAWS not reading properly current line if navigating up and down and when I start writing, at all pressed chars JAWS start reading entire Window from the top, so in Nano it always says the version, filename and the text starting from the top of the screen.

Originally created by @adns44 on GitHub (Dec 19, 2022). Originally assigned to: @carlos-zamora on GitHub. ### Windows Terminal version 1.15.221212005 ### Windows build number 10.0.19045.2364 ### Other Software JAWS For Windows 2023 ### Steps to reproduce Open an Linux SSH host with OpenSSH client and try to use nano to write or edit any text with multiple pines ### Expected Behavior JAWS reads the correct line by navigating up and down and don't start reading from the top of the window when I edit the text in nano. Seems that the problem relating to rendering but I'm not an expert in it. ### Actual Behavior JAWS not reading properly current line if navigating up and down and when I start writing, at all pressed chars JAWS start reading entire Window from the top, so in Nano it always says the version, filename and the text starting from the top of the screen.
claunia added the Needs-TriageIssue-BugProduct-TerminalArea-Accessibility labels 2026-01-31 06:33:49 +00:00
Author
Owner

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

Huh, I wonder if nano is being entirely redrawn each frame. That sounds insane, but could be possible. Or maybe it's an artifact of nano + ssh.exe + ConPty causing the Terminal to believe that all the lines were invalidated.

@carlos-zamora might know if we're already tracking something similar.

@zadjii-msft commented on GitHub (Dec 19, 2022): Huh, I wonder if `nano` is being _entirely_ redrawn each frame. That sounds insane, but could be possible. Or maybe it's an artifact of nano + ssh.exe + ConPty causing the Terminal to _believe_ that all the lines were invalidated. @carlos-zamora might know if we're already tracking something similar.
Author
Owner

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

Unfortunately, screen reader support for full screen TUI applications is a little thin on the ground. We're doing everything we can to standardize better integration with screen readers. But, as of today in 2023, this may not be easy to fix.

I suggest bringing this up as feedback for your AT provider to see if they can do anything differently to better figure out what changed on the screen and how to better present that.

For some background information, the issue here is that when text is output to the buffer, Terminal tells the screen reader that "something changed". The screen reader must then figure out what changed and announce that. We've added a feature to do better and say exactly what got output (i.e. "the letter a was output"), thus forcing the screen reader to immediately read that. However, this is pretty new and screen readers are investigating how to properly take advantage of that.

@carlos-zamora commented on GitHub (Jan 18, 2023): Unfortunately, screen reader support for full screen TUI applications is a little thin on the ground. We're doing everything we can to standardize better integration with screen readers. But, as of today in 2023, this may not be easy to fix. I suggest bringing this up as feedback for your AT provider to see if they can do anything differently to better figure out what changed on the screen and how to better present that. For some background information, the issue here is that when text is output to the buffer, Terminal tells the screen reader that "something changed". The screen reader must then figure out what changed and announce that. We've added a feature to do better and say exactly what got output (i.e. "the letter a was output"), thus forcing the screen reader to immediately read that. However, this is pretty new and screen readers are investigating how to properly take advantage of that.
Author
Owner

@adns44 commented on GitHub (Dec 28, 2025):

I started to work on this problem with a JAWS script and here is my first solution. I'm still try to fix issues, E.G. unneccessary or incorrect information read in ncurses windows (E.G. dpkg-reconfigure tzdata).
https://github.com/adns44/wt-access

@adns44 commented on GitHub (Dec 28, 2025): I started to work on this problem with a JAWS script and here is my first solution. I'm still try to fix issues, E.G. unneccessary or incorrect information read in ncurses windows (E.G. dpkg-reconfigure tzdata). https://github.com/adns44/wt-access
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#19101