Why does NVDA ignore the .NET Accessibility.Name and Accessibility.Role?

[tomb18]

I am the author of several software packages to control Amateur radios. The software is written in C#.NET Windows forms.
Any given control has two properties for Accessibility.Name and Accessibility.Role. NVDA does not work correctly when it encounters such a control.
If Accessibility.Name is set to a value, let's say "Mode", then it announces this correctly. If the accessibility.name field is null, it makes up its own name. It should not. If the accessibility.role is set to none, it should not try to interpret what the control is or does. It does what it pleases.
If using Microsoft Narrator, this functionality works correctly.
In view of this, I am forced to create my own accessibility for all the controls in my applications. This should not be.
I know that I can create a plug in. However, this means learning a new programming language, keeping up with the NVDA updates and so on. I do not have the time for such an endeavor. I'm a single developer with thousands of clients.
Now I can understand that if the Accessibility.Name property is not set, then NVDA makes it's own assumptions since so much software out there doesn't bother with this. However, this is incorrect. Widespread consideration of programming for accessibility will be enhanced if conventions are followed.
At the very least, there should be an option in NVDA to follow the .NET conventions for Accessibility Name and role. If this had been the case, .NET can provide the corresponding correct speech in just 2 lines of code. In my case I had to program 75 different controls.
I hope you can consider adding such an option for the future.
Tom

[josephsl]

Hi, it might be due to how NVDA recognizes .net controls on its own via properties such as window class name. The relevant NVDA source code to look at is source/NVDAObjects package, likely IAccessible package which houses MSAA overlay classes. Thanks.

[Brian1Gaff]

This seems like it might have a very wide remit and might improve a lot of small bits of software. I feel this might need to run up the fix list a bit. I was unaware of this, and though I'm no programmer, I think that NVDA should really follow the convention at least as well as Narrator does. Brian

…

-- ***@***.*** Sent via blueyonder.(Virgin media) Please address personal E-mail to:- ***@***.***, putting 'Brian Gaff' in the display name field. ----- Original Message ----- From: "Joseph Lee" ***@***.***> To: "nvaccess/nvda" ***@***.***> Cc: "Subscribed" ***@***.***> Sent: Monday, January 30, 2023 3:00 AM Subject: Re: [nvaccess/nvda] Why does NVDA ignore the .NET Accessibility.Name and Accessibility.Role? (Issue #14594)

Hi, it might be due to how NVDA recognizes .net controls on its own via properties such as window class name. The relevant NVDA source code to look at is source/NVDAObjects package, likely IAccessible package which houses MSAA overlay classes. Thanks. -- Reply to this email directly or view it on GitHub: #14594 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[zersiax]

This is a pretty big deal. If convention is outright ignored here that has quite a wide-spread effect on messaging to work specifically for NVDA. @tomb18 this may be a stretch but do you know if JAWS handles this correctly?

[rperez030]

I think it does. I've never heard JAWS or Narrator reading out class names like that.

[michaelDCurran]

Please provide a sample app and clear instructions on how to reproduce this behaviour.
Also, a reference to documentation that backs up your statement on "conventions" would be very helpful thank you.