RichTextBox always sends its entire contents as an accessibility event on focus

[trypsynth]

.NET version

10.0.202

Did it work in .NET Framework?

Not tested/verified

Did it work in any of the earlier releases of .NET Core or .NET 5+?

No response

Issue description

I previously opened an issue about this, but it got closed and the discussion locked after just a little bit of inactivity. However, I'm once again running into this, so re-creating an issue, as I believe the original reasoning for closing it is flawed.

If I create a RichTextBox, alt+tab away from the window, and alt+tab back, both JAWS and NVDA report the entire contents of the RichTextBox as its own accessibility event. This is not standard behavior. Oddly enough, narrator is not effected, reading nothing at all when the control takes focus.

using System.Windows.Forms;

ApplicationConfiguration.Initialize();
Form mainForm = new() { Text = "RichEdit Test", Width = 450, Height = 250 };
RichTextBox textBox = new() {
    AccessibleName = "Content",
    Text = "This is a test\r\nthat spans multiple\r\nlines.",
    Size = new Size(400, 200),
    Location = new Point(10, 10)
};
mainForm.Controls.Add(textBox);
Application.Run(mainForm);

Reason for re-creating

In #12772, @merriemcgaw said:

There is some risk in the implementation options available to us. After talking with our internal accessibility team, it seems that there is an easy way for the screen reader user to "hush" the reading once focus is received. In that case we don't have a compliance issue, and with the risk of making changes here it's better to let the additional content be sent to the AT.

I completely disagree with this assertion; this is 100% a compliance issue in my mind as a screen reader user who is also a software engineer.

The assertion that a user can simply "hush" the screen reader completely misses the reality of real-world application performance and UX. In my development work, I'm building a large-scale e-book and document reader. I ended up going with wxWidgets as a native widgets abstraction due to this Winforms bug, because when a RichTextBox holds an entire book, loading several megabytes of text into the control means that megabytes of data are forced across the MSAA/UIA boundary instantly upon focus, every, single, time. This can even freeze screen readers.

The argument that this isn't a compliance issue also falls flat when you look at how other standard Win32 and Windows Forms controls behave: A standard multi-line TextBox does not dump its entire contents into a focus event on Alt+Tab; it respects the cursor position or selected text. Microsoft Word and Notepad do not dump entire documents into the accessibility channel on focus either. Furthermore, as noted in the reproduction steps, Windows Narrator reads nothing at all on focus, proving that the underlying event emission is inconsistent and broken depending on how the AT consumes the UIA/MSAA tree for RichEdit.

If standard text input fields can handle focus gracefully without flooding the AT channel, RichTextBox should be held to the same standard. Leaving this unfixed effectively breaks the usability of RichTextBox for any accessibility-compliant application handling large text payloads, such as my Paperback ebook reader.

Steps to reproduce

1. Run the provided code with NVDA or JAWS active.
2. Alt+tab away from the window and back.
3. Note that the entire content gets read, not just the currently focused line.

[elachlan]

@trypsynth I'd suggest working on a pr to improve the situation.

If there is a proof of concept that improves a11y the team will probably be more likely to take it.

[trypsynth]

Okay, that I can do. I got demotivated from doing such things because a PR of mine fixing a long-standing accessibility issue in WPF has been sitting there for months, but the Winforms team seems much more in tune with accessibility.

[elachlan]

@trypsynth The team usually has a window that is earlier in the year to take features. Bug fixes like this are usually taken quickly depending on how overloaded they are. My observation is that microsoft hasn't funded them nearly enough for all the LOB applications out there.