Category: ARIA and Semantic Structure

ARIA Properties

Also known as: ARIA, WAI-ARIA properties, ARIA attributes

Simply put

ARIA properties are special attributes that web authors add to page elements to give assistive technologies, such as screen readers, extra information about how those elements behave and relate to one another. They are part of WAI-ARIA, a set of specifications published by the W3C to help make rich, interactive web content more accessible. Some ARIA properties apply only to specific roles, while others, known as global attributes, can apply to any element.

Formal definition

In the WAI-ARIA specification, properties are a category of ARIA attributes that expose semantic information about an element to the accessibility API, generally describing characteristics or relationships that are less likely to change during the element's lifecycle than ARIA states. ARIA states and properties together supply supplemental semantics for user interface components, and per MDN some are defined as 'Global' attributes that apply to all HTML elements regardless of whether an ARIA role is present. The W3C's WAI-ARIA specification enumerates the supported states and properties available to authors of rich internet applications, with detailed definitions for each. Note that the specific inventory of properties and their applicability can vary across WAI-ARIA versions; consult the current W3C specification for authoritative details.

Why it matters

ARIA properties are one of the primary mechanisms authors have for communicating the meaning and relationships of complex, interactive web components to assistive technologies. Native HTML elements often carry built-in semantics, but custom widgets built with generic elements like <div> and <span> may expose little or no meaningful information to a screen reader. Properly applied ARIA properties can help bridge that gap by exposing characteristics and relationships through the accessibility API, supporting the goals reflected in WCAG success criteria related to name, role, and value.

Because ARIA properties directly shape what an assistive technology user perceives, mistakes carry real consequences. Incorrect, missing, or contradictory ARIA can misrepresent a component's behavior or relationships, producing an experience that is more confusing than plain HTML would have been. The W3C guidance that inappropriate or excessive ARIA can be worse than none is widely echoed among practitioners, which is why ARIA is generally treated as a supplement to, not a replacement for, semantic HTML.

It is also important to distinguish conformance from usability and from legal compliance. Correctly using ARIA properties may support conformance with relevant WCAG criteria, but it does not by itself guarantee an accessible experience for all users, nor does it confer immunity from legal claims. Automated tools can detect only a portion of ARIA-related issues; manual review and testing with assistive technologies remain necessary. This entry is general information about a technical standard and is not legal advice; readers should consult the current W3C specification and, where relevant, qualified counsel.

Who it's relevant to

Front-end and accessibility engineers

Developers building custom or interactive components use ARIA properties to expose relationships and characteristics that generic markup does not convey. They should apply properties in accordance with the current WAI-ARIA specification, favor native HTML semantics where available, and verify results with assistive technology rather than relying on automated checks alone.

UX and interaction designers

Designers of rich, dynamic interfaces influence which components will need supplemental ARIA semantics. Understanding what ARIA properties can and cannot communicate helps designers plan components that map cleanly to the roles, states, and properties assistive technology users depend on.

QA and accessibility testers

Testers evaluate whether ARIA properties are used correctly and consistently, since incorrect or contradictory ARIA can degrade the experience. Because automated tools detect only a portion of ARIA-related issues, testers combine automated scans with manual review and screen reader testing.

Compliance officers and legal counsel

Those responsible for accessibility programs should understand that correct ARIA usage may support conformance with WCAG criteria commonly cited as targets, but does not guarantee an accessible experience or legal immunity. Requirements evolve through regulation and case law, and this entry is not legal advice; consult qualified counsel and current agency guidance for jurisdiction-specific obligations.

Inside ARIA

ARIA Properties (aria-* attributes)

A subset of WAI-ARIA attributes that define characteristics or relationships of an element to assistive technologies. Examples commonly cited include aria-label, aria-labelledby, aria-describedby, aria-required, and aria-haspopup. They supplement native HTML semantics where those semantics are insufficient.

Properties versus States

WAI-ARIA distinguishes properties from states. Properties generally describe stable characteristics that are less likely to change over the lifecycle of the element (for example aria-labelledby), while states describe conditions that commonly change in response to user interaction (for example aria-checked or aria-expanded). Both are expressed as aria-* attributes.

Relationship properties

Properties that establish associations between elements, such as aria-labelledby and aria-describedby, which reference the IDs of other elements to provide names or descriptions, and aria-controls or aria-owns, which express structural or controlling relationships.

Widget and live region properties

Properties that support custom interactive components and dynamically updating content, such as aria-haspopup for elements that trigger popups, and properties associated with live regions that influence how updates are announced.

Relationship to roles

ARIA properties are used alongside ARIA roles. A role commonly identifies what an element is, while properties and states describe its attributes and current condition. Certain roles support or require specific properties to convey complete meaning to assistive technologies.

Common questions

Answers to the questions practitioners most commonly ask about ARIA.

Do ARIA properties make an element accessible on their own?

No. ARIA properties modify how assistive technologies interpret an element, but they do not add behavior, keyboard support, or focus management. An element may expose the correct ARIA property and still be inaccessible if the underlying interaction is not implemented. ARIA generally supplements, rather than replaces, proper semantic markup and functional behavior. Where a native HTML element with built-in semantics and behavior exists, it is commonly preferred over recreating that semantics with ARIA properties.

Are ARIA properties the same thing as ARIA states or ARIA roles?

Not exactly, though the terms are related and sometimes used loosely. In WAI-ARIA, roles define what an element is, while properties and states describe characteristics of an element. Properties are generally attributes whose values are less likely to change over the course of an interaction, whereas states describe conditions that commonly change in response to user action. The distinction is one of convention within the specification rather than a difference in how the attributes are written, and readers should consult the current WAI-ARIA specification for the authoritative categorization of a given attribute.

How do I decide which ARIA property to apply to an element?

Selection generally starts with the role or purpose of the element and the information an assistive technology user needs to understand and operate it. Consult the WAI-ARIA specification and the ARIA Authoring Practices guidance for the properties associated with a given role. Before adding a property, consider whether a native HTML element or attribute already conveys the needed information, since duplicating or overriding native semantics can introduce errors. This is general guidance, not a substitute for testing with assistive technologies.

How should ARIA property values be kept accurate when the interface changes?

ARIA property and state values should reflect the current condition of the element they describe. When the underlying content or interaction changes, the associated attribute values generally need to be updated so that assistive technologies convey correct information. Stale or incorrect values can be more misleading than no ARIA at all. Verifying that values update correctly typically requires testing with screen readers and other assistive technologies, since automated checks detect only a portion of such issues.

How do I verify that ARIA properties are working as intended?

Verification commonly combines automated checks with manual and assistive technology testing. Automated tools can flag some problems, such as invalid attribute values or unsupported combinations, but they detect only a portion of issues and cannot confirm that the resulting experience is understandable and operable. Manual testing with screen readers, keyboard-only navigation, and other assistive technologies is generally needed to confirm that the exposed information matches the element's actual behavior and appearance.

What are common mistakes to avoid when implementing ARIA properties?

Frequently cited pitfalls include applying properties that do not correspond to an element's role, referencing element IDs that do not exist for properties that point to other elements, failing to update values when the interface changes, and using ARIA to patch missing behavior such as keyboard support rather than implementing that behavior. Overriding correct native semantics with ARIA is another common source of errors. Because implementation details and assistive technology support evolve, consult the current WAI-ARIA specification and authoring practices, and validate through testing.

Common misconceptions

Adding ARIA properties automatically makes a component accessible.

ARIA conveys semantics to assistive technologies but does not add behavior. Properties must be applied correctly, kept in sync with the interface, and paired with appropriate keyboard interaction and native semantics. Incorrect or excessive use can degrade the experience, which is why manual and assistive technology testing is generally needed rather than relying on the presence of attributes alone.

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

WAI-ARIA distinguishes properties, which generally describe more stable characteristics, from states, which commonly change in response to interaction. Both use the aria-* syntax, but treating them as identical can lead to attributes being applied where a role or native element would be more appropriate.

ARIA should be used to replace native HTML wherever possible.

A widely cited principle is to prefer native HTML semantics when a native element provides the needed role, states, and properties, and to use ARIA properties to fill gaps rather than to override existing semantics. Overuse can introduce conflicts and unexpected behavior in assistive technologies.

Best practices

Prefer native HTML elements and their built-in semantics first, and use ARIA properties to supplement only where native semantics are insufficient.

Ensure relationship properties such as aria-labelledby and aria-describedby reference valid, existing element IDs, and verify that the referenced content conveys the intended name or description.

Pair properties with the appropriate roles and keep any related states updated as the interface changes, so that what assistive technologies announce matches the visible state.

Test with multiple assistive technologies and manual keyboard interaction rather than relying solely on automated checks, since automated testing detects only a portion of ARIA-related issues.

Avoid applying redundant or conflicting ARIA properties on elements that already expose the same information natively, as this can confuse assistive technology users.

Consult current W3C WAI-ARIA documentation and authoring practices to confirm which properties a given role supports, since guidance and support evolve over time.