So looking into what the Storybook addon uses, it appears to be the Axe library at https://github.com/dequelabs/axe-core

It should be possible to use that with the wrappers that we get from mount() in the test cases. Untested, but I think something like adding an accessibility check to the snapshot cases might be enough. Example case with CdxButton

test.each( cases )( 'Case %# %s: (%p) => HTML', ( _, props, slot, done ) => {
	const wrapper = mount( CdxButton, { props: props, slots: { default: slot } } );
	expect( wrapper.element ).toMatchSnapshot();
	axe.a11yCheck(
		wrapper.element,
		{},
		function ( result ) {
			expect( result.violations.length ).toBe( 0 );
			done();
		}
	);
} );

aXe core would be our first choice. As Lucy Greco has shared from one of her a11y testing evaluations for UC Berkeley already 3(?) years ago at a Accessibility Camp Bay Area, aXe was the only testing tool not only to have least false positive results, it was also the only accessible tool in their evaluation.

Please also consider that we've got prior work accomplished for example in WMDE's lexeme/query builder/WiKit (jest-axe) work:

• T265299: Investigate integrating accessibility testing tools into development tooling or
• T303806: Investigate which is the best option for accessibility testing to new lexeme special page CI

And a newer evaluation by Readers Web team in T301184: Add automated accessibility tests in CI to generate accessibility benchmarks for Vector

I did some investigation from the links shared by Volker and the implementation created by Danny.

This are just for information only as more investigation and discussions are required, overall seems like one or more of the following options would be best for our workflow:

1. Add a eslint plugin to ensure accessibility is taken care of while developing (this has been done by the Lexeme team T307912
2. It is easy to implement
3. It will ensure accessibility is done during development saving time when opening Patches
4. it will break the build is it does not pass
5. It can slow machine and development as most dev environment are set to run eslint on save!
6. Add jest accessiblity tests on ALL of our test cases, or just one test per file. (this has been completed by the query builder team).
7. Simple to implement (see screenshot below)
8. It may result in many test cases to fail due to inconsistent or incomplete properties
9. It may not be very useful if we already pass have the eslint plugin
10. Create a Accessibility report in each documentation pages (not done anywhere, cannot find it on internet)
11. We could create a table with the result of AXA API and show all the pass and failure of the component
12. It would be great for component development too (as we use the docs for development too)
13. It will provide a nice visual indicator to people using our component of their standards
14. It may need a one off development effort