You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
…ree (#1022)
Adds:
- ScanOptions property settable to IntPtr for HWND of root of subtree to be scanned
- Teach PID descendants search to operate on HWND's subtree instead of GetRootElement
- Add Integration test for test app leaf node scan
Proposal to address issue #1021
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
The text was updated successfully, but these errors were encountered: