ScanAsync needs overloads to scan process's UIA sub-trees

[blackcatsonly]

Is your feature request related to a problem? Please describe.

When the UIA tree for the process-under-test is changing frequently, Axe.Windows' ScanAsync produces ScanResults that claim many Rule violations that are not reproducible.

Describe the solution you'd like

Add ScanAsync overloads that accept an IntPtr window handle for more targeted sub-tree scans

Describe alternatives you've considered

Scanning the full process takes too long. In a test or user environment where the UIA surface changes frequently, periodic scanners (like Dave's prototype) produce erroneous violations.
We'd love to have a way to tell the app to pause UI changes while we finish the scan, but no one seems to have a proposal to do that.
So, instead, we're looking to optimize the scan duration and make it less likely that the UIA will change before the pre-scan capture is completed.

Additional context

Sent: Monday, April 22, 2024 1:25 PM
Subject: Re: Help: Axe.Windows scans for volatile UIA

Thanks for the links - we saw the demo, but it doesn't solve our problem. We're using ScanAsync the way you suggest, but it's producing ScanResults that include erroneous claims about violations for missing patterns, null bounding rectangles, etc.

Would you please consider exposing a ScanAsync overload that takes an HWND (IntPtr)? I really want to scan only a very scoped portion of the overall tree, but I only see a way to pass the process ID?

Sent: Monday, April 22, 2024 1:05 PM
Subject: Re: Help: Axe.Windows scans for volatile UIA

Hi,

There is no way for axe-windows to pause another running app. Also, axe-windows does grab all the UIA data before it begins to process its rules, however, grabbing the UIA data is what takes time. These are hundreds or thousands of cross-process calls depending on the size of the UI. And that is a slow process which we have no way to speed up.

ScanAsync method should be used to ensure proper data isolation between scans. You can run scans on a timer , then capture the output and automatically deduplicate the results. You can try similar approach to trigger the scan based on UIA events.

Thanks,

Date: Wednesday, April 17, 2024 at 1:13 PM
Subject: Help: Axe.Windows scans for volatile UIA

Tl;Dr: Do you know how to pause Win32 Desktop app UI changes to avoid bogus Axe.Windows scans? Or tell the Axe.Windows scanner to avoid scanning volatile UI surfaces?

Details:

We are experimenting with ways to expand Accessibility Insights coverage by leveraging the existing Office Automation suite. There are too many features to cover and too many tests to modify manually, so we're attempting to alter the execution environment to passively produce .a11ytest output after the unmodified tests finish.

This is working okay - we trigger Axe.Windows scans from UIA event handlers that get invoked for notable changes in the product app's UI structure. We've found violations in several areas that are hard for vendors to test manually.

However, test actions or other execution context often closes dialogs or alters the UIA hierarchy, so we get outputs that flag a zillion violations for missing patterns, null bounding rectangles, etc.

We have some ideas about injecting pauses in our test actions, but we'd love to have tooling that could ensure the scan completes successfully:

Force the app to block UI changes
OR
Tell Axe.Windows to collect all the data it needs before attempting a scan

[JGibson2019]

Thank you @blackcatsonly for working to address this issue; I've updated the status accordingly

[codeofdusk]

A fix for this issue was recently released in Axe.Windows 2.4.0. Thanks again for your contribution @blackcatsonly!