[test][button] Add axe test coverage and docs

[mj12albert]

Result	Count
✅ Supports	23
⚠️ Partially Supports	4
❌ Does Not Support	0
➖ Not Applicable	28
🚩 Unverified	17/27

Doc: https://github.com/mj12albert/material-ui/blob/docs-button-axe-coverage/packages/mui-material/src/Button/accessibility.md

Expand axe test coverage for Button to cover as much of WCAG as possible, and document the component's current WCAG conformance and testing notes/procedures.

• I have followed (at least) the PR section of the contributing guide.

[code-infra-dashboard]

Deploy preview

https://deploy-preview-48708--material-ui.netlify.app/

Bundle size

Bundle	Parsed size	Gzip size
@mui/material	0B(0.00%)	0B(0.00%)
@mui/lab	0B(0.00%)	0B(0.00%)
@mui/private-theming	0B(0.00%)	0B(0.00%)
@mui/system	0B(0.00%)	0B(0.00%)
@mui/utils	0B(0.00%)	0B(0.00%)

Details of bundle changes

---

Check out the code infra dashboard for more information about this PR.

[siriwatknp]

@mj12albert the accessibility.md is not auto-generated right? I want to get alignment on the plan to make them public on the docs, what's your view on this?

[mj12albert]

the accessibility.md is not auto-generated right?

No ~ it's impossible to auto-generate (at least now) 😅, I kick-started research with AI but eventually had to manually re-do ~80% of it anyway, so for each I gave it my manual notes and initial draft as a start

Possibly once we have a few more of these, there will be more reference material that improves the results, but the fundamental issue is that AI is unreliable at "understanding" the WCAG specs (esp when there's no direct code to trace)

Possibly we can later automate the aggregation of component level scorecards:

| Result                | Count |
| :-------------------- | :---- |
| ✅ Supports           | 23    |
| ⚠️ Partially Supports | 4     |
| ❌ Does Not Support   | 0     |
| ➖ Not Applicable     | 28    |

into a library-level scorecard

I want to get alignment on the plan to make them public on the docs

I agree we should do this eventually, but that's a matter of presentation; for now I'm solely focused on scoring components, first so there is a body of content to present. IMO we don't need to worry about this until we have ~20 components scored. Does that make sense? @siriwatknp

[michelengelen]

Instead of individual reports I would like a table, where the findings are aggregated into a per level (A / AA) report. This could effectively look similar to this:

Component	WCAG 2.2 A	WCAG 2.2 AA
Button	✅ (8/8 )	⚠️ (5/12)

...

[mj12albert]

Yes, the component level ones can eventually be aggregated into being displayed something like this, though x/total AA may not accurately partial/irrelevant criteria, so far I'm just following a somewhat standard formats/terminology

[michelengelen]

Pretty hard to read. Can we maybe use an array of strings here that we define outside of the scope and just spread it here?

[mj12albert]

Updated, I think quite soon we can't pack everything in a single file either or it'll get ugly

[siriwatknp]

focused on scoring components

fair enough.

[siriwatknp]

The Unverified confuses me or at least better to present differently. In my understanding it means "not audited by trusted firms" right?

If yes, I think it's better to be removed and declare globally in accessibility.md instead on how we do audit manually.

Currently there are too many "Unverified" which is expected because we don't plan to do external audit soon.

[mj12albert]

@siriwatknp

Unverified basically means both:

1. It isn't covered by tests (because it's not test-able, e.g. resize, reflow), and
2. It hasn't been manually audited and recorded – we can audit it ourselves; I've verified most of them but just keeping them flagged for now because I didn't fully cover all OS/browser/SRs (e.g. on the Windows side I only tested NVDA+Edge, but JAWS is most popular SR and I don't have it)

Open to suggestion if you think Unverified sounds bad 😅 but they need to be flagged somehow regardless

I haven't thought in depth about how to document manual audit records, not sure if it should be docs committed into the repo or something else as it will require manual maintenance

[mj12albert]

Updated in 49a91ae to separate the flags from the official criteria with a simpler explanation