Inconsistent reporting of UI Automation elements #3530
Assignees
Labels
bug
Something isn't working
Comments
1 task
DaveTryon
added a commit
to microsoft/axe-windows
that referenced
this issue
Jun 2, 2023
#### Details microsoft/accessibility-insights-windows#1625 points out that the `ChromiumComponentsShouldUseWebScanner` rule is flagging items that are outside the context of a web page, which goes against the rule's primary purpose. This change limits the `ChromiumComponentsShouldUseWebScanner` rule to elements within a HTML document (including the document itself). While working on this, we discovered a bug in WebView2, which is tracked at MicrosoftEdge/WebView2Feedback#3530. ##### Motivation Address microsoft/accessibility-insights-windows#1625 ##### Before & after ###### Text results using Edge As expected, only the `ChromiumComponentsShouldUseWebScanner` rule is impacted Rule | Count Before | Count After --- | --- | --- An element of the given ControlType must not support the invoke pattern | 1 | 1 An on-screen element must not have a null BoundingRectangle property | 7 | 7 Chromium components should be scanned with a web-based scanner | 211 | 135 The Name must not include the same text as the LocalizedControlType | 5 | 5 The Name property must not contain only whitespace | 3 | 3 The Name property must not include the element's control type | 1 | 1 The Name property of a focusable element must not be null | 10 | 10 ###### Screenshots using Edge These screenshots are limited to just the `ChromiumComponentsShouldUseWebScanner` rule: State | Screenshot --- | --- Before change |  After change |  ##### Context This includes an opportunistic optimization to some of the code in `Relationships`, because the unit test code looked odd with arbitrary multipliers to compensate for hoe `Relationships` is coded. This could be a separate PR if that's preferred. <!-- Were there any alternative approaches you considered? What tradeoffs did you consider? --> #### Pull request checklist <!-- If a checklist item is not applicable to this change, write "n/a" in the checkbox --> - [x] Addresses an existing issue: microsoft/accessibility-insights-windows#1625
|
I'm also able to reproduce this issue in Google Chrome Canary 116.0.5806 when |
|
@codeofdusk, thank for your reply! |
|
Is there any update? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
The WebView2 control is inconsistent in what UIA elements it reports. The first time its UIA elements are enumerated, only a partial set is returned. On subsequent enumerations, the full set is consistently returned. This occurs in Edge, in the WebView2 samples, and with a tiny test app that we created separately. This behavior does not occur in Chrome, so it seems unlikely that this is a Chromium bug.
Version
SDK: Unknown
Runtime: 113.0.1774.57 (as reported by Control Panel)
Framework: WinForms (also happens with WPF)
OS: Win11 22H2
Repro Steps
.a11ytestfiles in Accessibility Insight for Windows and comparing the reported hierarchies. As demonstrated below, the contents of the Document control are completely absent from the first test.Screenshots
AxeWindowsCLI.exe --outputdirectory %userprofile%\desktop --scanid 1 --processid 9196AxeWindowsCLI.exe --outputdirectory %userprofile%\desktop --scanid 2 --processid 9196AxeWindowsCLI.exe --outputdirectory %userprofile%\desktop --scanid 3 --processid 9196Comparisons of 1st iteration and 2nd iteration in Accessibility Insights for Windows. The selected element is identical in each, but the first set of results omit the Document control containing the HTML.
Additional context
The text was updated successfully, but these errors were encountered: