[Feature Request] Make scans against Chromium-based UIs more actionable

[dbjorge]

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

This issue is based on discussion with @RobGallo and @DaveTryon after several customer interactions where users attempting to scan apps that are Chromium-based get confused.

The most common case is a user trying to scan a browser (Edge, Chrome, etc) with their page loaded, but we've also seen cases where a user has their own Windows app that embeds Chromium (eg, via Electron or WebView2).

There are two related problems that happen when a user does this:

• Most ATs special case Chromium instances such that it's a lot more useful for practical accessibility purposes to scan web content with a web scanner like Accessibility Insights for Web, rather than with axe-windows/Accessibility Insights for Windows. However, axe-windows results don't make any mention of this, even though we could easily distinguish these cases programmatically (by looking for a FrameworkId UIA property of "Chrome").
• Even with an absolutely minimal WebView2 usage serving an empty page with no issues, there are a few low-severity issues that axe-windows flags that are essentially framework issues (~10 BoundingRectangleNotNull violations). Users can't do anything about these, but we don't currently treat them as framework issues.

Describe the solution you'd like

Rob and I think we'd ideally handle this on the axe-windows side similarly to how we treat old edge - create a rule which specifically detects an embedded chromium instance (via FrameworkId "Chome") and present a specific error that directly instructs users to scan the contents of the browser with a web-based scanner. Such a rule should probably somehow suppress any further errors in descendants of the root "Chrome" element - this will require some new form of handling, we don't currently have any other rules that do this type of subtree suppression.

It's a little questionable to call this an "Error" since we don't really want to treat it as an error to use a WebView2 at all, but we don't really have a better means to present actionable feedback to a user about needing an extra step for scanning such a component. I think that a single actionable error would clearly be a lot better than the current case of "dozens or hundreds of inactionable errors", though.

Describe alternatives you've considered

• The real gold standard in terms of customer ease-of-use might be to actually perform an axe-core scan inside the detected chromium instance somehow. But we think this would probably be technically infeasible to do automatically unless the Chromium instance were accepting CDP debugger commands, and it would be a huge chunk of work to present it reasonably.
• It would be good to investigate/file bugs against the BoundingRectangleNotNull violations that are consistently present regardless of page content. We did some initial investigation and think this is probably an issue on the Chromium side rather than the WebView2/MSAA_Proxy side, but didn't nail down an exact location. If we wanted to follow up on this, good contacts to reach out to for more context would be the folks marked as the Chromium windows accessibility platform OWNERS. However, we think pushing on these are pretty low priority; the issues themselves are such low severity that we think it would be hard to get traction on them, so if we end up making the proposed rule above that would mask them anyway, it doesn't feel worth the effort to try to drive them to resolution.

Additional context

n/a

[ghost]

This issue has been marked as ready for team triage; we will triage it in our weekly review and update the issue. Thank you for contributing to Accessibility Insights!

[ferBonnin]

Triaged with the team.
We will show a Framework rule error and then eliminate or not scan the Chromium component

[microsoft-github-policy-service]

This issue requires additional investigation by the Accessibility Insights team. When the issue is ready to be triaged again, we will update the issue with the investigation result and add "status: ready for triage". Thank you for contributing to Accessibility Insights!

[DaveTryon]

After discussion in Windows triage, this will require some fundamental changes. We feel this needs to be treated as a full feature and not as a kluge fix.

[microsoft-github-policy-service]

This issue requires additional investigation by the Accessibility Insights team. When the issue is ready to be triaged again, we will update the issue with the investigation result and add "status: ready for triage". Thank you for contributing to Accessibility Insights!

[DaveTryon]

The Chromium rule now triggers exactly once for each Chromium Document. All rules are suppressed for elements within the Chromium Document

[codeofdusk]

Released as part of 2.2.0. Closing as complete.