ARIA Basics: HTML First

ARIA — Accessible Rich Internet Applications — is a set of attributes you can add to HTML elements to communicate additional meaning to assistive technologies. It is powerful. It is also frequently misused in ways that make pages less accessible, not more.

The rule that governs this module: HTML first. ARIA only when HTML is not enough.

What ARIA is

ARIA attributes add semantic information that HTML alone cannot express. They fall into three categories:

Roles — what an element is:

<div role="button">Click me</div>

Properties and states — what an element’s current condition is:

<button aria-expanded="false">Menu</button>
<input aria-required="true" type="text">

Labels and descriptions — text that names an element:

<nav aria-label="Primary navigation">...</nav>
<button aria-label="Close dialog">×</button>

ARIA attributes are read by screen readers and other assistive technologies. They have no visual effect whatsoever.

Why HTML comes first

Most ARIA attributes solve problems that semantic HTML already solves — without any extra attributes.

What you need	HTML solution	ARIA solution
A button	<button>	<div role="button" tabindex="0">
A navigation landmark	<nav>	<div role="navigation">
A labeled form field	<label for="id">	aria-labelledby
A required field	required attribute	aria-required="true"
A checkbox	<input type="checkbox">	<div role="checkbox" aria-checked="false">

The ARIA version requires more code, adds complexity, and can break if the ARIA attributes are used incorrectly. The HTML version is built into the browser — it is keyboard accessible, correctly announced, and handles all state changes automatically.

This is the principle: native HTML elements have accessibility built in. ARIA attributes have to be maintained manually.

No ARIA is better than bad ARIA

ARIA does not make pages more accessible by default. Used incorrectly, it actively harms accessibility.

<!-- This tells screen readers the div is a button -->
<!-- But it is not keyboard focusable, cannot be activated with Enter or Space -->
<!-- and has no built-in state management -->
<div role="button" onclick="submit()">Submit</div>

<!-- This is correct — all button behaviors work by default -->
<button onclick="submit()">Submit</button>

When you apply a role="button" to a <div>, the screen reader announces it as a button — but it does not gain keyboard focus, cannot be activated with Enter or Space, and cannot be disabled with the disabled attribute. You have created a false expectation. A keyboard user navigates to what they believe is a button and cannot activate it.

The phrase used in the ARIA specification is: “No ARIA is better than bad ARIA.”

If you do not know whether an ARIA attribute is correct, do not use it. Wrong ARIA is worse than no ARIA.

When ARIA is appropriate

At this stage of the course — building static HTML pages with native elements — you will rarely need ARIA. It becomes necessary primarily for:

Custom interactive components. A dropdown menu built from <div> elements needs role="menu", role="menuitem", aria-expanded, and keyboard event handling to be accessible. A <select> element needs none of this.

State that HTML cannot express. A button that toggles an expandable panel needs aria-expanded="true" or aria-expanded="false" — there is no HTML attribute for this.

Labeling landmark regions. When a page has two <nav> elements, a screen reader user navigating the landmark list sees “navigation” twice. Adding aria-label to each distinguishes them:

<nav aria-label="Primary">...</nav>
<nav aria-label="Footer">...</nav>

Describing non-text interactive elements. An icon button with no visible text label needs aria-label:

<button aria-label="Close dialog">
  <svg aria-hidden="true">...</svg>
</button>

Note the aria-hidden="true" on the SVG — it removes the icon from the accessibility tree so the screen reader does not try to read it as content. Only the button’s aria-label is announced.

The three ARIA attributes you will encounter most

aria-label — provides an accessible name for an element when no visible text is available:

<button aria-label="Search">
  <img src="search.svg" alt="">
</button>

aria-hidden="true" — removes an element from the accessibility tree entirely. Use for purely decorative content that would be noise for screen reader users:

<span aria-hidden="true">★★★★☆</span>
<span class="sr-only">4 out of 5 stars</span>

The sr-only class is a CSS utility that visually hides the element while keeping it readable by screen readers. The HTML alone does nothing — it requires a CSS rule to work. You will implement this in CSS Foundations. For now, the pattern shows the intent: one version for visual display, one for assistive technology.

aria-expanded — communicates whether a collapsible element is currently open or closed. Required for custom toggles and accordions:

<button aria-expanded="false" aria-controls="menu">Navigation</button>
<ul id="menu" hidden>...</ul>

Exercise

Review your Summit Trail Outfitters pages for situations where ARIA would be appropriate:

1. Multiple <nav> elements — if index.html, tours.html, or other pages have both a header nav and a footer nav, add aria-label="Primary" to the header nav and aria-label="Footer" to the footer nav.

2. Icon-only elements — if any link or button contains only an image or SVG with no visible text, add aria-label to the link or button. Add aria-hidden="true" to the image or SVG inside it.

3. Decorative content — if any visible decoration (star icons, decorative separators) would be read as content by a screen reader, add aria-hidden="true".

4. Forms — confirm the contact form uses <label> elements rather than aria-label. At this level, native labels are always preferred.

Do not add ARIA to elements that already work correctly with native HTML. Only add it where there is a real gap.

Recap

• ARIA attributes let you communicate roles, properties, states, and labels to assistive technologies.
• ARIA has no visual effect — it only affects what screen readers announce.
• Semantic HTML already handles most accessibility needs. Reach for ARIA only when HTML is insufficient.
• Incorrect ARIA is worse than no ARIA — a wrong role creates false expectations that break keyboard and screen reader use.
• The most common ARIA attributes at this level: aria-label (naming unlabeled elements), aria-hidden="true" (hiding decorative content), and aria-expanded (indicating toggle state).
• For the Summit Trail Outfitters site, the only ARIA that may be needed is aria-label on <nav> elements and aria-hidden on decorative icons.