Native support for UIA patterns

[IrinaPykhova]

a lot of people are trying to automate UI testing. So, we often get requests about automation support from our customers. Currently, in WinForms it is very tricky to support and we haven't found any good documentation about that.

As a third-party vendor, we'd like WinForms to have some level of native support for UI Automation, similar to WPF implementation: https://docs.microsoft.com/en-us/dotnet/api/system.windows.automation.peers.frameworkelementautomationpeer?view=windowsdesktop-6.0
I think, it might improve automation support for Microsoft controls as well

[RussKie]

Can you please elaborate what exactly you're trying to accomplish?

Windows Forms controls support a number of UIA patterns, including but not limited to:

• Text and TextRange Control Patterns
• ExpandCollapse Control Pattern
• Invoke Control Pattern
• ScrollItem Control Pattern
• LegacyIAccessible Control Pattern

More information is available in

• https://devblogs.microsoft.com/dotnet/whats-new-in-windows-forms-runtime-in-net-5-0/#accessibility-improvements-and-fixes
• https://devblogs.microsoft.com/dotnet/whats-new-in-windows-forms-in-net-6-0/#accessibility-improvements-and-fixes

[gc-deniszmitrichenko]

Hi @RussKie,
We want to have some embedded support for Control class to implement UIAutomation instead of Active Accessibility.
In WinForms we have ControlAccessibleObject and AccessibleObject classes for implementing Active Accessibility, which we can inherit, override some properties/methods and get some result. But Active Accessibility is old, it doesn't support control patterns and there is no way to add control pattern to implemented Active Accessibility.
So, we need to add support for UIAutomation to obtain control pattern support and there is no infrastructure inside Control class to have it - we need to implement all basic interfaces (IRawElementProvider, IRawElementProviderFragment, IRawElementProviderFragmentRoot) from scratch each time, override WndProc to handle corresponding messages (by the way MS page here https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/expose-a-server-side-ui-automation-provider has mistake in the sample how UIAutomation should be enabled - m.LParam.ToInt32() will fail with exception on 64-bit systems).
This repo already has 3 years old issue about it - #1834.
We want to have the same.

[merriemcgaw]

As @RussKie mentioned, we've been working very hard to try to migrate WinForms from MSAA which is woefully outdated and natively support UIA directly from our controls. It's still a work in progress but we're getting there. I LOVE the idea of trying to get this in for .NET 7. I will circle back with @vladimir-krestov and my Accessibility specialists to see what the cost is and the risks of breaking any other existing workarounds other customers may have implemented.

But all that said, #1834 definitely does move the needle forward on support for accessibility and on our goal to provide a completely accessible UI Framework.

[RussKie]

(by the way MS page here docs.microsoft.com/en-us/dotnet/framework/ui-automation/expose-a-server-side-ui-automation-provider has mistake in the sample how UIAutomation should should be enabled - m.LParam.ToInt32() will fail with exception on 64-bit systems).

Thank you for pointing it out, I'll have it updated.

There's a magic button that helps getting docs issues fixed :)

[IrinaPykhova]

@RussKie as Denis described, we want to have some level of embeded support for it in WinForms, similar to what MS did in WPF where you can inherit from existent AutomationPeer class and extend it. Implementing everything from scratch for every single thing is complicated and error prone