←  All terms
A
Accessibility

ARIA

ARIA adds semantic information for assistive technologies when native HTML elements do not provide enough context.

ARIA adds semantic information for assistive technologies when native HTML elements do not provide enough context. Implementation should favor native web standards and combine automated checks with keyboard and assistive-technology testing. The concept is closely related to Semantic HTML and Screen Reader.

Read more

Semantic HTML

Screen Reader

Web Accessibility

Keyboard Navigation

FAQ

ARIA

How can correct ARIA implementation be verified?
Automated checks find invalid attributes and roles. Whether names and states actually sound sensible only becomes clear when testing with a screen reader and keyboard. Testing in at least one common browser and screen reader pairing is advisable, since output can differ between combinations.
How does ARIA differ from semantic HTML?
Semantic HTML ships with role, state, and keyboard behavior built in, while ARIA only adds descriptions for assistive technologies. Native elements are therefore easier to maintain and less error-prone. ARIA fills gaps where HTML falls short and never replaces it.
What typical mistakes occur when using ARIA?
Frequent problems are conflicting roles, states like aria-expanded that are never updated, and attributes placed on elements that do not support them. ARIA only changes what assistive technologies are told, not how the element behaves. Keyboard interaction and focus management still have to be implemented in code.
When should ARIA be used, and when not?
ARIA belongs only where no native HTML element provides the needed semantics, such as tab components or live regions. A button element beats a div with role=button. Incorrectly applied ARIA attributes often make accessibility worse than using none at all.