♿ Advanced HTML

Accessibility (a11y)

⏱ 2 hr2 topicsLive playground
🎯 By the end: You can make a page keyboard-usable, write meaningful alt text and labels, use native interactive elements, and apply ARIA only when you truly need it.

Accessibility (often shortened to a11y — 'a', then 11 letters, then 'y') means building so that people with disabilities can use your site: those who are blind, have low vision, can't use a mouse, or are hard of hearing. The wonderful part? Most of it is just good HTML, which you've already been learning. This lesson ties it together.

1Use the right element — it does the work for you

The single biggest accessibility win is using the correct native element. A real <button> is focusable with the keyboard, fires on Enter and Space, and is announced as "button" — all for free. A <div> styled to look like a button is none of those things; a keyboard user simply cannot reach it.

The same idea runs through everything you've learned:

  • <img alt="…"> — describe what the image shows.
  • <label for> — name every form field.
  • Semantic landmarks (<nav>, <main>) — let users jump around.
  • Heading order (one <h1>, no skipped levels) — gives a navigable outline.
Try the playground below with your keyboard: press Tab. The real button receives focus and works with Enter; the fake div button is skipped entirely.
Real button vs fake button
HTML
CSS
Live preview
What's happening: Both look identical, but only the real <button> can be reached with the Tab key and activated with Enter or Space. The styled <div> is invisible to keyboard and screen-reader users — always use the right element.
Key points
  • Using the correct native element (e.g. <button>) gives keyboard support and screen-reader naming for free.
  • A <div> styled as a button can't be reached by keyboard users.
  • alt text, labels, semantic landmarks and heading order are all accessibility features you've already learned.

2Keyboard, focus and a little ARIA

Many people navigate entirely by keyboard. Two rules keep them happy:

  • Everything interactive must be reachable by Tab and operable by Enter/Space. Native elements handle this; custom widgets need extra care.
  • Never hide the focus outline. That glowing ring around the focused element shows keyboard users where they are. If a design removes it, you must add a clear replacement — removing it with outline: none and nothing else is an accessibility failure.

ARIA — the seasoning, not the meal

ARIA attributes (like aria-label or role) add accessibility information when HTML alone isn't enough — for example, aria-label="Close" on an icon-only button. But the first rule of ARIA is: don't use ARIA if a native element already does the job. Reaching for role="button" on a div is worse than just using a <button>.

Bad ARIA is worse than no ARIA — it can actively mislead screen readers. Use native HTML first; add ARIA only to fill a genuine gap.
Key points
  • Every interactive element must be reachable by Tab and work with Enter/Space.
  • Never remove the focus outline without providing a clear visible replacement.
  • Use ARIA only to fill gaps native HTML can't — prefer the right element over role hacks.

★ Practical: a keyboard-friendly mini page

In any playground, build and then Tab through:

  1. A real <button> and confirm it receives focus on Tab.
  2. An image with meaningful alt text.
  3. A form field with a linked <label>.
  4. Check every interactive thing is reachable by keyboard alone.

Ready to test yourself?

Take the short quiz. Score 60% or more to mark this lesson complete.

Start the quiz →

💡 Log in to save your progress and earn the certificate.

← Previous
Iframes
Next →
SEO with HTML