Screen Reader Accessibility Issue on Windows: Repeats Previous Line Instead of Announcing 'Blank' for Empty Lines in PyQt6 and PySide6 QTextEdit and QPlainTextEdit Widgets

Hello

I using PyQt6 and testing out a variety of widgets available and how accessible they are for screen reader users.
There is a problem with how screen readers on Windows are reading multi-line text from `QTextEdit` and `QPlainTextEdit` widgets in PyQt6 and PySide6 applications.

1. 1. Behavior

The problem is basically this: rather than reading "blank" for the empty line, it reads a previous line instead.

1. 1. 1. For example:

This is line 1
blank line
And this is line 2

It would be read like so:
This is line 1
This is line 1
And this is line 2

1. 1. Expected Behavior

It should be read like so:

This is line 1
"blank" (The spoken text for the new line)
And this is line 2

1. 1. Extra Info

• I tested this with NVDA and JAWS screen readers on Windows, and the problem is exactly the same on both.
• *Python version:* 3.9
• *PyQt version:* PyQt6 6.7.1 (the latest version as of this post date)
• The same behavior persists in rich text view and plain text view.
• The same behavior exists whether text editing is allowed or not.

1. 1. Reported Issue

I reported this on the QT forum: [Screen Reader Accessibility Issue on Windows: Repeats Previous Line Instead of Announcing 'Blank'](https://forum.qt.io/topic/159911/screen-reader-accessibility-issue-on-windows-repeats-previous-line-instead-of-announcing-blank-for-empty-lines-in-pyqt6-qtextedit-and-qplaintextedit-widgets)
I also reported this on the NVDA GitHub page and it was confirmed again it's a QT issue not a screen reader issue: NVDA Repeats Previous Line Instead of Speaking "Blank" for Empty Lines in PyQt6 Applications for QTextEdit and QPlainTextEdit Widgets #17419(https://github.com/nvaccess/nvda/issues/17419)

1. 1. Final Thoughts

I hope you can have a look and investigate it because this library is great and supports accessibility quite well. However, there are some quirks that need to be looked at.

There are more problems that I am able to find that can be attributed to the actual framework problem rather than the screen reader behavior. However, I'm reporting one issue at a time as suggested. Let's get this fixed before reporting another one, I guess.

please have a look because accessibility is important ideally I would like to use this framework to create some accessible UI applications it just needs some screen reader user testing for sure.