Category: ARIA and Semantic Structure

ARIA States

Also known as: WAI-ARIA states, ARIA state attributes

Simply put

ARIA states are special attributes added to web page elements that describe the current condition of an element, such as whether a checkbox is checked or a menu is expanded. These conditions typically change as a user interacts with the page, and they help assistive technologies like screen readers announce what is happening. They are part of WAI-ARIA, a set of roles and attributes developed by the W3C to make rich, interactive web content more accessible.

Formal definition

ARIA states are a subset of WAI-ARIA attributes that convey the current, dynamic condition of an element to the accessibility tree, as defined in the W3C WAI-ARIA specification. Unlike ARIA properties, which tend to describe more stable characteristics of an element, states generally change in response to user interaction or application events (for example, aria-checked, aria-expanded, or aria-selected), and authors are typically responsible for keeping their values updated in sync with the element's actual condition. The distinction between states and properties is somewhat conceptual, and the two are formally grouped together as 'states and properties' in the specification and applied as attributes; authoring rules for their correct use in HTML are addressed by the ARIA in HTML specification. Correct implementation requires manual and assistive technology testing, as proper markup alone does not guarantee an accessible experience.

Why it matters

ARIA states matter because much of today's web relies on dynamic, interactive components, custom checkboxes, expandable menus, toggle buttons, and selectable lists, whose current condition may not be conveyed to assistive technologies through native HTML alone. When an element's condition changes as a user interacts with the page, screen readers and other assistive technologies depend on accurate state information in the accessibility tree to announce what has happened. Without correct ARIA states, a user relying on a screen reader may not know whether a menu is expanded, whether a checkbox is checked, or whether an item is selected.

Because states generally change in response to user interaction or application events, keeping their values synchronized with the element's actual condition is an ongoing authoring responsibility rather than a one-time markup task. A state attribute that is present but stale, for example, an aria-expanded value that never updates when a control is toggled, can be more misleading than no attribute at all, because it communicates a condition that no longer reflects reality.

It is important to note that correct ARIA markup is necessary but not sufficient. Proper use of ARIA states does not by itself guarantee an accessible experience, and automated tools detect only a portion of potential issues. Manual review and testing with actual assistive technologies are generally required to confirm that states are announced correctly to users. Nothing here should be treated as legal advice; organizations with compliance questions should consult qualified counsel and current guidance.

Who it's relevant to

Front-end and accessibility engineers

Developers building custom interactive components are directly responsible for applying ARIA state attributes and keeping their values synchronized with each element's actual condition as users interact with the page. They should follow the authoring rules in the ARIA in HTML specification and verify behavior through manual and assistive technology testing rather than relying on markup or automated checks alone.

UX and interaction designers

Designers who specify dynamic behaviors, expandable menus, toggles, and selectable lists, help determine which conditions need to be communicated to assistive technology users. Understanding how ARIA states convey element conditions to the accessibility tree supports designs that can be built accessibly and announced accurately.

Quality assurance and accessibility testers

Testers verify that state attributes reflect the true, current condition of elements as they change, and that these changes are announced correctly by assistive technologies. Because automated tools detect only a portion of issues, testers play a key role in the manual and assistive technology testing needed to confirm correct implementation.

Compliance officers and accessibility program leads

Those responsible for accessibility programs should recognize that correct ARIA state usage is one technical component of a broader accessibility effort and does not on its own guarantee an accessible experience or legal compliance. This guidance is not legal advice; requirements evolve through regulation and case law, and qualified counsel should be consulted on specific obligations.

Inside ARIA States

State Attributes

ARIA states are attributes that convey the current, dynamic condition of an element to assistive technologies, such as whether a control is checked, expanded, pressed, selected, or disabled. Unlike ARIA properties, which describe more stable characteristics of an element, states typically change in response to user interaction.

aria-checked

Indicates the checked state of checkboxes, radio buttons, and other elements with a checkable role. It can take values of true, false, or mixed (for tri-state controls).

aria-expanded

Indicates whether a collapsible element, such as an accordion or disclosure widget, is currently expanded (true) or collapsed (false), helping users understand and navigate dynamic content.

aria-selected

Communicates the selection state of items within widgets such as tabs, listboxes, and grids, allowing assistive technology users to know which option is currently selected.

aria-pressed

Indicates the pressed state of a toggle button, taking values such as true, false, or mixed, so that assistive technologies can convey whether the toggle is active.

aria-disabled

Signals that an element is perceivable but not currently operable. This differs from the native HTML disabled attribute, which also removes the element from the tab order and interaction.

aria-hidden

Indicates whether an element and its descendants are exposed to the accessibility tree. When set to true, the content is generally hidden from assistive technologies while potentially remaining visible on screen.

Dynamic Value Updates

Because states reflect changing conditions, their values are commonly updated through scripting as the user interacts with a component. Keeping the state value synchronized with the actual visual and functional state is essential for accurate communication to assistive technologies.

Common questions

Answers to the questions practitioners most commonly ask about ARIA States.

Are ARIA states the same thing as ARIA properties?

Not exactly. Both are ARIA attributes that convey information to assistive technologies, but they differ in how frequently their values change. States, such as aria-checked, aria-expanded, or aria-disabled, generally reflect conditions that change as a user interacts with an element. Properties, such as aria-label or aria-labelledby, generally describe more stable characteristics of an element. The distinction is one of convention and expected volatility rather than a strict technical boundary, and the ARIA specification groups them together as states and properties for this reason.

Does adding ARIA states automatically make a custom component accessible?

No. ARIA states only communicate information to assistive technologies; they do not add behavior. For example, setting aria-expanded does not itself open or close anything, and setting aria-checked does not toggle a control. You must implement the corresponding keyboard interaction, focus management, and visual updates in your own code, and keep the ARIA state value synchronized with the actual state. ARIA is often described as changing only how something is exposed to assistive technology, not what it does. Meeting the relevant WCAG success criteria and delivering a usable experience also requires manual and assistive technology testing, since automated tools detect only a portion of issues.

How do I keep an ARIA state value synchronized with what the user actually sees?

The ARIA state attribute should be updated in the same code path that changes the component's underlying state and its visual presentation. For instance, when a disclosure control is activated, the script that shows or hides the associated content should also update aria-expanded to true or false. A stale or contradictory state value can be more confusing to assistive technology users than no ARIA at all, so treat the attribute update as a required part of each state change rather than an afterthought.

Should I use a native HTML element instead of applying ARIA states?

Where a native HTML element provides the needed semantics and behavior, it is generally preferable to use it rather than recreating the functionality with ARIA. Native elements such as checkboxes, buttons, and disabled form controls expose their state to assistive technologies and handle keyboard interaction without additional scripting. ARIA states are most useful for custom widgets that have no native equivalent. A commonly cited guiding principle is to prefer native semantics first and reach for ARIA only when native markup cannot express the required role or state.

What is the correct value format for ARIA states like aria-checked or aria-expanded?

Most ARIA state attributes expect specific string values rather than arbitrary text. Many use true or false, and some, such as aria-checked or aria-pressed, also support a mixed value for tri-state controls. The attribute must be present with an explicit value; omitting the attribute is not the same as setting it to false, because the two conditions can be exposed differently to assistive technology. Consult the ARIA specification for the allowed value type of each specific attribute before implementing it.

How can I verify that ARIA states are being announced correctly?

Testing ARIA states generally requires more than automated checks. Automated tools can flag some invalid or missing attributes, but they cannot confirm that a state change is announced clearly or at the right moment. Manual testing with assistive technologies, such as screen readers across different browser and device combinations, is commonly needed to confirm that a state change is conveyed to users as intended and that keyboard interaction updates the state as expected. This should be part of a broader testing process rather than a single pass.

Common misconceptions

ARIA states and ARIA properties are the same thing and can be used interchangeably.

While both are ARIA attributes, states generally represent dynamic conditions that change during interaction (such as aria-expanded or aria-checked), whereas properties tend to describe more stable characteristics of an element. The distinction matters for how and when values should be updated in the interface.

Adding ARIA state attributes automatically makes a custom widget accessible.

ARIA states only convey information to the accessibility tree; they do not add behavior. Developers must also implement the corresponding keyboard interaction, focus management, and scripting to keep the state values accurate. Applying ARIA without matching functionality can create a confusing or misleading experience, and testing with assistive technologies is needed to confirm the result.

aria-disabled behaves the same as the native HTML disabled attribute.

aria-disabled communicates a disabled state to assistive technologies but does not by itself remove the element from the tab order or prevent interaction. The native disabled attribute does both. Choosing between them depends on whether the element should remain focusable and perceivable.

Best practices

Prefer native HTML elements and attributes where they provide the needed state semantics, and reserve ARIA states for custom components that lack a native equivalent.

Update state attribute values dynamically through scripting so they remain synchronized with the element's actual visual and functional condition throughout user interaction.

Ensure that ARIA states are paired with the expected keyboard interaction and focus management, since states describe conditions but do not create behavior.

Use each state attribute only on roles that support it, and set valid values (for example, true, false, or mixed where applicable) to avoid unpredictable assistive technology behavior.

Test components with multiple screen readers and assistive technologies in addition to automated checks, since automated tools detect only a portion of potential issues and cannot fully verify that state changes are announced correctly.

Review ARIA usage against current W3C authoring guidance, and treat this entry as general information rather than a guarantee of WCAG conformance or legal compliance.