Forma saysAccessible HTML works for everyone — semantic tags, alt text, labels, keyboard nav, and ARIA only where needed.
Most accessibility is just good HTML: real headings, a <button> instead of a clickable div, labels on inputs, alt on images. Assistive tech relies on this structure to describe and navigate the page.
ARIA attributes (role, aria-label, aria-live) fill gaps semantics can't — but the first rule of ARIA is don't use ARIA if a native element does the job. And every interactive thing must be reachable and operable with the keyboard (Tab to focus, Enter/Space to activate).
Power-ups you unlock
Semantics first — native elements are accessible by default
Rule of ARIA: don’t use it if HTML already does the job
Everything operable by keyboard, with visible focus
aria-live announces dynamic updates to screen readers
Captain Invalid Input attacks — common mistakes
Clickable <div>s with no role, tabindex, or keyboard handler
Removing focus outlines without providing a replacement
Slapping ARIA roles on elements that already have them
Boss battleTake a clickable <div> and rebuild it as a real <button>. Then Tab through the page and confirm focus is visible on each control.
Example code
<!doctype html>
<html><head><meta charset="utf-8"></head>
<body style="background:#06040d;color:#e6e0ff;font-family:sans-serif;padding:20px">
<nav aria-label="primary">
<a href="#a">home</a> · <a href="#b">about</a>
</nav>
<button onclick="this.textContent='activated by click OR Enter/Space'"
style="margin-top:12px;font:inherit;color:#b388ff;background:none;border:1px solid #b388ff;padding:8px 14px;border-radius:3px">
a real, keyboard-operable button
</button>
<p aria-live="polite" style="margin-top:10px;color:#8aff9d">live region: updates here get announced</p>
</body></html>