FSM Full Stack Masterclass
Platform under construction
HTML course badge

HTML Attributes

Intermediate

HTML Accessibility Attributes

Learn aria-*, role, aria-label, aria-labelledby, aria-describedby as part of the HTML attribute system: what they configure, where they belong and which mistakes to avoid.

Accessibility

Accessibility attributes clarify interfaces when semantic HTML is not enough.

Semantic HTML should always be the first choice. A real button is better than a div with role="button". ARIA and related attributes are useful when you need to label, describe or expose dynamic interface state.

Accessibility attributes can help, but they can also lie. If the attribute says one thing and the interface does another, assistive technology receives the wrong information.

Attribute group: aria-*, role, aria-label, aria-labelledby, aria-describedby. Attributes that help assistive technology understand interface intent.

What belongs here

Learn attributes by purpose, not by memorizing random names.

aria-label

Gives an accessible name when visible text is missing.

aria-labelledby

Uses another element as the accessible name.

aria-describedby

Connects extra help or error text.

aria-expanded

Exposes open/closed state for disclosure controls.

aria-live

Announces dynamic updates.

role

Adds or changes semantic role when native HTML cannot do it.

Syntax in context

ARIA should match visible behavior.

Use ARIA to clarify, not to decorate. Prefer native elements when they already provide the correct semantics.

<button type="button" aria-expanded="false" aria-controls="menu">
  Menu
</button>
<nav id="menu" hidden aria-label="Main navigation">
  <a href="/">Home</a>
</nav>

Good versus weak

Small attribute choices can change behavior, accessibility and security.

Good

<button type="button" aria-expanded="false" aria-controls="menu">
  Menu
</button>
<nav id="menu" hidden aria-label="Main navigation">
  <a href="/">Home</a>
</nav>

Weak

<div role="button" onclick="openMenu()">Menu</div>
<button aria-expanded="true">Menu</button>

Rules that matter

Use these rules before publishing real HTML.

Native first

Use button, nav, main, label and input before reaching for ARIA.

Keep state truthful

aria-expanded must change when the panel opens or closes.

Name icon buttons

An icon-only button needs aria-label or visible text.

Do not over-ARIA

Wrong ARIA can be worse than no ARIA.

Production thinking

Attributes are tiny pieces of HTML with real product impact.

Why does this matter?

ARIA exists to fill accessibility gaps when native HTML cannot fully describe a custom interface. Use semantic elements first, then add ARIA only when it tells assistive technology something true and necessary.

Accessibility

These attributes directly affect screen reader output and keyboard workflows. Test them like product behavior, not decoration.

Production note

Dynamic UI needs state synchronization. If JavaScript opens a menu, it should also update hidden and aria-expanded.

Live code lab

Change the code and run the example.

Edit the HTML or CSS, then use Run to refresh the preview. The preview is isolated, so links and forms stay inside this practice area.

Mini assignment

Try this now.

  • Change aria-expanded from "false" to "true".
  • Change aria-controls so it no longer matches the paragraph id, then change it back.
  • Run the preview and explain why the visible interface and ARIA state must tell the same story.

Practice assignment

Do this before moving to the next lesson.

  1. Change one meaningful part of the HTML, not only the visible text.
  2. Run the preview and check whether the result still makes semantic sense.
  3. Explain why the element or attribute you changed belongs in this exact place.

Try it yourself

Accessible disclosure button

Live preview

Self-check

Before you continue, prove that you own this lesson.

Intermediate

Do not only read this page. Answer these questions out loud or write the answers in your own notes. If one answer feels vague, revisit the examples before moving on.

  1. Can you explain what problem this lesson solves in a real website?
  2. Can you identify the most important tag or attribute from this lesson?
  3. Can you name one accessibility mistake this lesson helps prevent?
  4. Can you write one good example and one weak example without copying the page?
  5. Can you explain when you would use this in production and when you would avoid it?