Fixing invalid ARIA attribute values

4.1.2 Name, Role, Value · Level A W3C: Understanding 4.1.2

Each ARIA attribute accepts a defined set of values. aria-expanded takes true, false or undefined; a value such as "open" is ignored, so a screen reader cannot tell whether the section is expanded.

Who this affects: People who use screen readers, who are told nothing about the control's state or the wrong thing.

The failing markup

<button type="button" aria-expanded="open" aria-controls="answer-1">Can I cancel at any time?</button>
<div id="answer-1">Yes, from your account page.</div>

How to fix it

Use the values the ARIA specification defines for the attribute: true or false for aria-expanded and aria-pressed, and an existing id for aria-controls.
Update the value in the same code that opens and closes the section, so the state announced always matches what is on screen.

The change

- Removed: <button type="button" aria-expanded="open" aria-controls="answer-1">Can I cancel at any time?</button>+ Added: <button type="button" aria-expanded="true" aria-controls="answer-1">Can I cancel at any time?</button>  <div id="answer-1">Yes, from your account page.</div>

Verified by the scanner

On 2026-09-13 both versions of this sample were run through Accessibility Pro's scan pipeline with arc-style, axe-core, ibm-equal-access, pa11y, focus-graph. The failing markup was reported as:

axe-core: aria-valid-attr-value, WCAG 4.1.2
ibm-equal-access: ibm-aria_attribute_value_valid, WCAG 4.1.2

The fixed markup produced no findings at all. To run the same check on every pull request, use the accessibility GitHub Action; how accurate the scanner is overall is in the published benchmark.

Worth knowing

Prefer native elements where they exist. A <details> and <summary> pair exposes its expanded state without any ARIA.