ARIA5: Exposing UI State with WAI-ARIA Attributes

For a sighted user, a pressed button looks pressed — maybe it changes color, shifts inward, or displays a checkmark. For a screen reader user relying on a button with no aria-pressed attribute, that same button is silent about its state. The interaction happens. The visual feedback happens. The semantic communication to assistive technology does not.

This is the gap that WCAG Technique ARIA5 (opens in new window) addresses directly.

The Technique

ARIA5 describes how to use WAI-ARIA state and property attributes to expose the current state, properties, and values of user interface components — and critically, to notify assistive technology when those values change. The technique is listed as sufficient for meeting WCAG 4.1.2 Name, Role, Value (opens in new window), the success criterion requiring that UI components programmatically expose their name, role, and current state so assistive technologies can read and set them.

The W3C document grounds this in two concrete examples that cut to the heart of the problem: a toggle button and a slider — two of the most commonly misimplemented interactive patterns on the web.

Why This Matters

The failure mode here is invisible to most developers during testing. A toggle button that mutes audio still works when you click it. The audio mutes. The icon changes. But a screen reader user navigating by keyboard hears "Mute button" — both before and after activation. Nothing in the accessibility tree signals that the state has changed. They have no reliable way to know whether audio is currently muted or not.

For keyboard-only users, switch device users, and anyone relying on a screen reader, stateless interactive components create a genuinely disorienting experience. Custom widgets built without ARIA state attributes are effectively black boxes: they accept input but provide no feedback through the accessibility layer. The user acts into a void.

This problem scales. The more custom UI a team builds — accordions, disclosure widgets, tab panels, custom checkboxes, sliders, comboboxes — the more surface area exists for state communication failures. And unlike missing alt text, these failures are largely invisible to automated testing tools. As our research on testing methodology documents, automated tools catch at most 37% of accessibility issues — and dynamic state management failures are squarely in the 63% that automation misses.

How It Works

The W3C document's toggle button example shows the pattern clearly. An <a> element is given role="button" and initialized with aria-pressed="false":

<a tabindex="0" role="button" id="toggle" aria-pressed="false">
  Mute
</a>

The JavaScript then toggles the attribute value on each activation:

function toggleButtonState(button) {
  var isAriaPressed = button.getAttribute('aria-pressed') === 'true';
  button.setAttribute('aria-pressed', isAriaPressed  'false' : 'true');
}

When aria-pressed transitions from "false" to "true", screen readers announce the state change. VoiceOver says "Mute, toggle button, pressed." NVDA announces "pressed." The user now has the same information a sighted user gets from the visual state change.

The slider example from the source material extends this to a range widget with role="slider", aria-valuenow, aria-valuemin, and aria-valuemax. Without these attributes, a custom slider communicates nothing about its current value or range to assistive technology. With them, the component becomes fully navigable and legible:

<div role="slider"
     aria-valuenow="50"
     aria-valuemin="0"
     aria-valuemax="100"
     aria-label="Volume">
</div>

As the user adjusts the slider, JavaScript updates aria-valuenow dynamically. Assistive technology reads the current value continuously.

The full list of WAI-ARIA state and property attributes is defined in the WAI-ARIA specification (opens in new window), and the ARIA Authoring Practices Guide (opens in new window) provides role-by-role implementation patterns.

Applying This

For development teams, the operational challenge with ARIA5 isn't understanding the technique — the W3C examples are clear. The challenge is systematic coverage across a codebase that may have dozens of custom interactive components, built by different developers, at different times, with different levels of accessibility awareness.

In code review, establish a checklist question for any custom interactive component: "Does this component expose its current state via ARIA attributes, and does the JavaScript update those attributes on every state change?" This catches the most common failure: the initial aria-pressed attribute is present, but the JavaScript that updates it was never written or was removed during a refactor.

In automated testing, tools like axe-core can flag missing required ARIA attributes on known roles (a role="slider" without aria-valuenow will trigger a violation). Configure your CI pipeline to run axe against interactive states, not just page load. A toggle button in its initial state may pass; the same button after interaction may not — if your tests only check the initial DOM, you're testing half the component.

In design systems, the highest-leverage fix is building ARIA state management into component primitives. A <ToggleButton> component in a React or Vue design system should handle aria-pressed internally — developers consuming the component shouldn't have to remember to wire it up. This is the difference between accessibility as a checklist and accessibility as infrastructure. The compliance framework research we've published makes clear that sustainable accessibility requires embedding standards into systems, not relying on individual developer recall.

Quick wins for teams starting from zero:

• Audit all <button> and role="button" elements that visually appear to toggle. Add aria-pressed and wire the JavaScript.
• Audit custom sliders, spinners, and range inputs. Verify aria-valuenow updates dynamically.
• Check accordion and disclosure widgets for aria-expanded on trigger elements.

Longer-term, incorporate ARIA state requirements into your component acceptance criteria at the design stage — before a line of code is written.

CORS Perspective

Through an operational capacity lens, ARIA5 is a high-ROI, medium-effort fix for teams with existing JavaScript skill. The technique requires no new tooling, no third-party libraries, and no architectural changes — just disciplined attribute management in code that already exists. The risk profile under WCAG 4.1.2 (opens in new window) is real: custom widgets without state exposure are clear Level A failures, the floor of conformance. Strategically, embedding ARIA state management into design system components converts a recurring per-component cost into a one-time infrastructure investment — which is exactly the kind of sustainability argument that moves accessibility from a compliance burden into an engineering standard. The community impact is direct: every screen reader user, every keyboard navigator, every switch device user gets the same state information that sighted users receive through visual design. That parity is what equal access actually looks like in code.