[General Question] Why does axe-windows not include axe-core and its rules?

[ChristoWolf]

Hi!

I think the question speaks for itself.

For example, axe-windows scans do not include basic WCAG rules like color contrast evaluation. This also implies that FastPass tests using Accessibility Insights for Windows do not scan/report such issues.

What is the reasoning there?

[codeofdusk]

Axe-core is a web-based scanning engine that runs in the context of a web browser, with web-centric rules to match. Since Axe-windows runs at the UI Automation level and its rules centre the desktop application, it isn't able to interrogate the document object model (DOM) of web applications in the same ways, and Axe-core rules are inappropriate for the desktop context. Accessibility Insights for Windows does include colour contrast evaluation tools, but these aren't exposed in Axe-windows' public interfaces at this time.

[ChristoWolf]

Thanks for the quick response @codeofdusk!

Yeah I figured, I've seen then that axe-core actually inspects the DOM.

but these aren't exposed in Axe-windows' public interfaces at this time

I thought that this could be done using the ColorContrastAnalyzer?

[DaveTryon]

@ChristoWolf, the DOM supports direct query of the colors in an element; UIA does not. The ColorContrastAnalyzer attempts to infer the colors by scanning a bitmap that corresponds to the on-screen element. It uses heuristics to identify the colors, and it's only sometimes accurate. We've evaluated different ways to improve its accuracy, but without much success. Users can trigger automatic color from Accessibility Insights for Windows (docs), but not from Axe.Windows scans. Our team has no current plans to add this integration.

Thanks for using Axe.Windows! Please feel free to open a new issue if you have additional questions 😄

[ChristoWolf]

Thanks for the insights @DaveTryon! In that case I will simply wrap ColorContrastAnalyzer in my APIs. Are you open for any other tools similar to this analyzer that could be contributed?