Skip to content

Chapter 3 of 8

Semantic HTML and ARIA

Semantic HTML is the foundation of accessible markup. Using built-in elements like <button>, <nav>, <main>, <label>, and <table> conveys meaning and behavior to the browser and assistive technologies without any extra work. A <button>, for example, comes with keyboard support, focus behavior, and screen reader semantics by default, while a <div> styled to look like a button carries none of those guarantees. Whenever a native element can do the job, it should be used first; this is often called the first rule of ARIA: do not reach for ARIA when semantic HTML already provides the answer.

ARIA, the Accessible Rich Internet Applications specification, provides a set of attributes that can improve semantics when native HTML is not enough. ARIA is divided into roles that define what an element is, such as role="button", role="dialog", role="menu", role="tab", or role="alert", and states and properties that describe its current condition, like aria-expanded, aria-selected, aria-pressed, aria-disabled, aria-invalid, aria-required, aria-busy, aria-controls, aria-current, and aria-haspopup. Two attributes handle naming directly: aria-labelledby references the ID of an element whose text serves as the accessible name, while aria-label provides a string when no visible text exists. The accessibility name calculation follows a consistent precedence: aria-labelledby wins, then aria-label, then the native label such as a <label for> association or alt text, then the element's text content, and finally the title attribute as a last resort.

ARIA can also remove elements from the accessibility tree when they are purely decorative. aria-hidden="true" hides content from assistive technologies and is appropriate for redundant icons or visual flourishes, though content already hidden with display: none does not need an additional aria-hidden. The role="presentation" attribute similarly removes the implicit role of an element such as a layout <table>. Common misuse of ARIA, such as adding a role that conflicts with native semantics or using ARIA to add visual appearance rather than meaning, frequently makes interfaces less accessible rather than more. Because ARIA does not add behavior, a <div> with role="button" still needs keyboard handlers, a tabindex, and visible focus styling; native elements give all of that for free.

All chapters
  1. 1Foundations of Web Accessibility
  2. 2The POUR Principles in Practice
  3. 3Semantic HTML and ARIA
  4. 4Keyboard Navigation and Focus Management
  5. 5Visual Accessibility
  6. 6Forms, Images, and Document Structure
  7. 7Dynamic Interfaces and Complex Components
  8. 8Testing, Cognitive Accessibility, and Inclusive Design

Drill it

Reading is not remembering. These come from the Web Accessibility deck:

Q

What is web accessibility?

Web accessibility is the practice of building websites and apps that people with disabilities can perceive, understand, navigate, and use.

Q

Why does accessibility matter?

It improves inclusion, usability, legal compliance, and overall product quality for everyone.

Q

What is WCAG?

WCAG stands for Web Content Accessibility Guidelines, the main standard used to evaluate digital accessibility.

Q

What are the four WCAG principles?

Content should be Perceivable, Operable, Understandable, and Robust.