feat(standards/ariaAttrs): add caseInsensitive property for attributes - #5224

Thanks for tackling this — the caseInsensitive flag is a nice cleanup. A few things to address before merge, mostly around consistency and finishing the replacement.

Important

1. Leftover { lowercase: true } for the now-caseInsensitive attrs. Some call sites weren't updated:

• lib/rules/aria-hidden-focus-matches.js:10 still passes { lowercase: true } for aria-hidden (this file isn't in the PR at all).
• lib/checks/aria/aria-valid-attr-value-evaluate.js:54 and :78 still pass it for aria-expanded, which is inconsistent with aria-required-attr-evaluate.js where the PR removed the same pattern.

These are redundant now and undercut the stated goal of the PR. A repo-wide grep for lowercase: true would confirm none of the four flagged attrs still pass it.

2. Doc/test typo caseInsenstive. doc/standards-object.md:54 and the test name at test/commons/aria/get-aria-value.js:128 spell it caseInsenstive — the actual property is caseInsensitive, so the docs describe a property that doesn't exist.

3. aria-selected is treated case-insensitively but not flagged in the standard. aria-valid-attr-value-evaluate.js:57 lowercases aria-selected via { lowercase: true }, but aria-selected in the standard is not marked caseInsensitive. So axe already treats it case-insensitively at this one call site while the standard says it's case-sensitive. WAI-ARIA treats enumerated token values as case-insensitive generally, so as part of this work we should test the remaining token props to confirm whether they're actually still case-sensitive, and mark them accordingly (or intentionally leave them and document why — see below). At minimum aria-selected should be reconciled so behavior doesn't depend on the call site.

Suggestions

4. Document why some token props are left case-sensitive. Since the spec treats enumerated token values as case-insensitive but this PR flags only four attributes, add a note (in lib/standards/aria-attrs.js and/or the doc) explaining why the remaining token attributes are intentionally left case-sensitive in Axe. Where we don't have test data yet, we'll need to run the tests.

5. Redundant optional chaining. Now that getAriaValue always returns an object, remaining ?.value calls (e.g. aria-valid-attr-value-evaluate.js:45) are dead defensiveness and mix styles within the file. Low priority.

I can live with leaving testing of those lesser used props for another time, but in that case please open an issue.

Nice work — 58cb8a08 is a good deal more than was asked for. 20 of the 23 token/boolean attrs now carry an explicit caseInsensitive value, and the per-AT rationale comments on the nine false ones are genuinely useful to have in the standard.

A few things I checked that seem worth recording:

• Every removed { lowercase: true } maps to an attribute now marked caseInsensitive: true — all 8 call sites (aria-invalid, aria-hidden ×3, aria-expanded ×3, aria-haspopup, aria-selected, aria-live, aria-disabled). No silent loss of lowercasing.
• The getAriaValue return-shape change isn't a breaking change: lib/commons/aria/get-aria-value.js is absent from v4.11.4, v4.12.0 and v4.12.1, and getAriaValue appears nowhere in doc/. It's never shipped, so there's no public contract to break.
• Items 1, 3 and 5 from the first round all check out on this head — zero lowercase: true left in lib/ (the three remaining hits are tests of the option itself on aria-label), aria-selected is now flagged in the standard, and zero ?.value left in any changed lib file.

One process thing: @WilcoFiers asked for an issue if the lesser-used props were left untested, and I couldn't find one. #4618 is the only open case-sensitivity ticket and it's a broad 2024 "go over the code base" item that doesn't name these attributes, and there's no Closes line on this PR. Worth filing before merge so that condition is actually met.

Plus a question inline about the aria-selected test that lost its uppercase case, and a note on aria-attrs.js about the three unresolved attrs.