Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
TheQuinbox opened this issue Jan 13, 2025 · 7 comments
Labels
area-controls-RichEdit tenet-accessibility MAS violation, UIA issue; problems with accessibility standards
Milestone

Comments

@TheQuinbox
Copy link

.NET version

DotNet 9.0

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

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.
Form1.cs:

namespace RichEditTest;

public class Form1 : Form {
	private RichTextBox textBox;

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

Program.cs

namespace RichEditTest;

static class Program
{
    /// <summary>
    ///  The main entry point for the application.
    /// </summary>
    [STAThread]
    static void Main()
    {
        // To customize application configuration such as set high DPI settings or default font,
        // see https://aka.ms/applicationconfiguration.
        ApplicationConfiguration.Initialize();
        Application.Run(new Form1());
    }    
}

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. Seemingly it's being sent as its own accessibility event.
@TheQuinbox TheQuinbox added the untriaged The team needs to look at this issue in the next triage label Jan 13, 2025
@elachlan elachlan added tenet-accessibility MAS violation, UIA issue; problems with accessibility standards area-controls-RichEdit labels Jan 14, 2025
@elachlan
Copy link
Contributor

@Olina-Zhang can your team please test?

@Olina-Zhang
Copy link
Member

Tested it in .NET versions and .NET framework 4.8.1, they have same result:
For NVDA, when alt+tab away from the window and back, it will announce the first line content, but Narrator doesn't announce.

NVDA:

Image

Narrator:

Image

@Zheng-Li01
Copy link
Member

Below are the results for MFC project between Narrator and NVDA tools.

Image

@merriemcgaw
Copy link
Member

@TheQuinbox thank you so much for filing this issue! This is a great find. That said, it looks like this is an issue with the RichEdit control itself, rather than WinForms specifically. Unfortunately, I think one would need to file an issue with the Office team, but I don't recall if there is any active development of the control.

@TheQuinbox - could you file a feedback ticket with Windows (because it is distributed with Windows) and if you can provide a link here, we can do our best to pull together a case for someone to take a look at the issue. I'm going to close this from our end, but we want to make sure the right owners are notified of the issue.

@dotnet-policy-service dotnet-policy-service bot removed the untriaged The team needs to look at this issue in the next triage label Jan 14, 2025
@TheQuinbox
Copy link
Author

Hello,
Thanks for your reply! I don't think this is an issue with the rich text box control itself, because there are applications I've seen use it without this behavior whatsoever. For example, https://github.com/samtupy/Pipe2Textbox. That's a very small C program with no CRT that links against the Win32 API only, so it should show you pretty trivially.
Thanks again!

@TheQuinbox
Copy link
Author

Hi @merriemcgaw,
Are there any updates on this issue? Plans to reopen it/etc, at the very least? Unless you can provide me with a test case to confirm this is indeed specific to the rich edit control in native Win32. I don't find this likely though as rich edit controls in both wxWidgets and native Win32 C don't exhibit this behavior.
Thanks for your time,
Quin.

@merriemcgaw merriemcgaw reopened this Jan 31, 2025
@merriemcgaw
Copy link
Member

merriemcgaw commented Jan 31, 2025

@TheQuinbox Thank you for pushing back, you made us look more closely. And, of course, you are correct. We've pinpointed where we are sending the entire contents. during the OnGotFocus() event.

It looks like this code was added several years ago in response to nothing being sent to Narrator when getting focus, which is a clear violation of accessibility guidelines. Obviously sending then entire contents of the RichTextBox every time the control gets focus is not performant or reasonable when you've got a lot of text. We'll look on our side at what MFC exactly does, but I'm interested from the assistive technology user perspective, what would you find appropriate to be sending? If you have a large RichTextBox with lots of content, what is it that you would want announced by NVDA/Jaws/Narrator? I think we have the potential here to optimize for both performance and user experience.

@LeafShi1 can your team take a look at the sources for the MFC control and see what it is sending when it gets focus? At the very least we can mimic that behavior. I'd like to see this in .NET 10 for sure.

FYI @Tanya-Solyanik

@merriemcgaw merriemcgaw added this to the .NET 10.0 milestone Jan 31, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-controls-RichEdit tenet-accessibility MAS violation, UIA issue; problems with accessibility standards
Projects
None yet
Development

No branches or pull requests

5 participants