dotnet
Screen-reader reads lines twice in a TextBox / TextBlock / RichTextBox
- .NET Core Version: 7.0.0-rc.1.22426.10
- Windows version: 22H2
- Does the bug reproduce also in WPF for .NET Framework 4.8?: Yes
- Is this bug related specifically to tooling in Visual Studio? No
Problem description: When reviewing line by line a multi-line TextBox with a screen-reader (Narrator or NVDA), the screen-reader will always read a line of text twice as long as there is a blank line above said line of text. The user will either think that the line of text is present twice or that the text navigation is broken.
Actual behavior: When using down arrow to go line by line in a TextBox, Narrator / NVDA will read some lines of text twice, even though the line is there only once.
Expected behavior: Just like any other text edit, the screen-reader only reads the current line of text once when cursor moves down or up by one line.
Minimal repro:
- Setup the WPF project Option 1: Download TextBoxUIABugRepro.zip and open the .sln file in Visual Studio. Option 2: Create a new WPF project, and in MainWindow.xaml.cs add the onInitialize override with the following code:
protected override void OnInitialized(EventArgs e)
{
base.OnInitialized(e);
var tb = new TextBox();
tb.AcceptsReturn = true;
var layout = new StackPanel();
layout.Children.Add(tb);
this.Content = layout;
tb.Text = "Hello, this is a test\r\n\r\nThis is a second line of text, you will notice that if you move focus to the line above this line, you will also hear this line, this makes Narrator read it twice.\r\n\r\nAgain, you will hear this third line twice";
tb.Focus();
}
- Start debugging
- Put your text cursor at the very beginning of the textbox (Ctrl+Home).
- Start Narrator (Ctrl+Win+Enter, or from Start menu). You can also use NVDA.
- With focus in the textbox, press the down arrow
- Notice that when you are on line 2, which is blank, Narrator / NVDA will read the third line of text.
- Press the down arrow again
- This time Narrator and NVDA read line 3 correctly, reading line 3 for the second time.
- Keep pressing down and up arrow to notice how Narrator / NVDA will read the line of text below a blank line instead of reading "blank".
Additional information I might be wrong in this section, I just thought since I did more investigation I would put it here in case it's useful.
This seems like a UIA provider bug.
When debugging WPF, I noticed that in TextRangeAdapter.cs --> line 522: private void ExpandToEnclosingUnit(TextUnit unit, bool expandStart, bool expandEnd)
- When cursor is on line 2, _start is right at the start of line 2, however _end is at the start of line 3. When the line unit expansion is done, the text range now covers both lines 2 and 3.
- This is the symptom however, the problem must come from how _start and _end state is managed. The expansion is doing the right thing here, except that _end should not be on line 3, but on line 2.
Other notes:
- This repro uses Windows style line endings (CrLf, \r\n), however the issue repros no matter what line ending used (\r,\n,\r\n).
- This issue is not limited to TextBox, but also TextBlock, RichTextBox, and I'm guessing anything using the TextRangeAdapter or at least TextView.
- Although this is a WPF bug and not a NVDA bug, this issue was filed in 2011 on NVDA's repo, here it is for reference: NVDA reads text in a standard WPF text box incorrectly
A good reference implementation for expected UIA text range behaviour is MS Word (winword.exe).
Any progress on this? This problem has plagued screen reader users for more than a decade.
cc: @siagupta0202, @anjali-wpf, @Arpitmathur, @dipeshmsft, @Himgoyalmicro, @harshit7962 could someone please look into this? It impacts alot users in multiple scenarios, especially when using braille displays and the same line is shown on the display although the caret moved to a different line. The same happens with speech from the screen reader. It would be really nice to see some improvements to accessibility of WPF in this regard.
Still no updates on this? This has been an issue since at least 2011 and it's just remained unfixed for at least 13 years. We've heard nothing from the team at all, other than @rchauhan18 being assigned back in 2022, almost three years ago.
Microsoft does not seem to care about this at all, and I am disappointed.
@msftedad is there any official position from Microsoft on this? WPF is being used in a lot of third party applications and we still have serious accessibility problems not being fixed since many years. Could you share this with the development team and give us some indication of what Microsoft intends to do about it?