Purpose and content model
ARIA adds accessibility semantics when native HTML alone does not express the necessary relationship or state. Role identifies a semantic role; aria-* attributes can supply names, descriptions, relationships, and changing states. They do not create keyboard behavior, rendering, or application logic. A div with role=button remains incomplete until the required interaction is implemented.
Start with native elements such as button, label, input, details, and dialog. Add ARIA only where it fills a real gap and is permitted on that element. Some elements prohibit naming or particular roles, so a global-looking aria attribute is not automatically valid in every context.
Syntax and working example
<button type="button" aria-expanded="false" aria-controls="filters" id="filter-toggle">Filters</button>
<section id="filters" hidden><h2>Filter results</h2></section>
<!-- Application code must keep hidden and aria-expanded synchronized. -->Supported attributes and behavior
Aria-labelledby references one or more IDs that provide a name; aria-describedby references descriptions. Aria-label supplies a text name but can override visible content and should not casually replace it. Aria-expanded describes a control's expanded state, aria-controls points to controlled content, and aria-current marks a current item. Aria-live requests announcement behavior. Aria-hidden removes content from accessibility exposure but does not remove keyboard focus or visually hide it.
Another practical pattern
<label for="email">Email address</label>
<input id="email" type="email" aria-describedby="email-help">
<p id="email-help">We use this address for your registration confirmation.</p>
<p role="status" id="save-status"></p>Accessibility and browser notes
Use W3C ARIA in HTML for permitted combinations and the ARIA Authoring Practices Guide for complete interaction patterns. Do not rely only on automated checks: an attribute can be syntactically valid while announcing the wrong state or creating a confusing name. Keep visible labels consistent with accessible names for speech input.
Common mistakes
Do not add aria-hidden=true to focusable controls or an ancestor containing them. Do not duplicate native checked state with conflicting aria-checked. An aria-live region that updates on every keystroke can overwhelm the user, while an empty label can erase useful semantics.
Verify your implementation
Inspect computed accessible names, roles, and states in developer tools, then operate the interface with a screen reader and keyboard. Open and close each disclosure and verify state synchronization. Check every referenced ID and use a real status update to confirm announcements are useful.
Standard status and sources
Standard; browser availability must be checked independently of specification status.