Everything so far has used plain HTML, and that is deliberate. HTML elements come with roles, names, states and keyboard behaviour built in. But sometimes HTML runs out. There is no native element for a toggle button’s pressed state, for a set of tabs, or for “say this out loud when the basket changes”. That is where ARIA (Accessible Rich Internet Applications) comes in: a set of attributes that let you describe roles, states and relationships directly to the accessibility tree.
\nThe W3C’s own guidance starts with a rule that surprises people: if you can use a native HTML element with the behaviour you need, do that instead of ARIA. WebAIM’s annual scans of the top million home pages keep finding that pages using ARIA have more detected errors, not fewer. The reason is simple. ARIA only changes what is announced. It doesn’t make anything focusable, doesn’t add keyboard handling, and doesn’t change appearance. Every ARIA attribute is a promise to assistive technology that your JavaScript then has to keep.
\n<!-- A promise with nothing behind it -->\n<span role=\"button\">Add to basket</span>\n\n<!-- The same promise, kept by the browser -->\n<button type=\"button\">Add to basket</button>ARIA attributes fall into three groups.
\nRoles say what something is: role="tab", role="dialog", role="switch", role="status". You rarely need them for things HTML already has.
Properties describe relationships or fixed characteristics: aria-labelledby and aria-describedby (you used both on forms), aria-controls, aria-required, aria-haspopup.
States describe things that change as the user interacts, and your script must update them: aria-expanded, aria-pressed, aria-checked, aria-selected, aria-current, aria-disabled, aria-invalid.
Ticketly’s wishlist heart is a good example. It is already a real button, but nothing tells a screen reader whether the event is saved. aria-pressed turns it into a toggle button:
<button type=\"button\" class=\"fav\" aria-pressed=\"false\">Save to wishlist</button>fav.addEventListener('click', () => {\n const saved = fav.getAttribute('aria-pressed') === 'true';\n fav.setAttribute('aria-pressed', String(!saved));\n});NVDA now says “Save to wishlist, toggle button, not pressed”, then “pressed” after activation. Notice that the label stays the same; the state carries the change. And you can style from the state directly, which keeps the visuals and the semantics from drifting apart:
\n.fav[aria-pressed='true'] {\n background: #5b3cc4;\n color: #fff;\n}For the current page in a navigation menu, aria-current="page" tells screen reader users which link they are on: “Tickets, current page, link”.
A few more rules from the W3C’s “Using ARIA” note keep you out of trouble:
\n<h2 role="button"> destroys the heading. Put a button inside the heading instead.When Ticketly adds a ticket, the basket counter in the header changes from 1 to 2. Sighted users notice. Screen reader users hear nothing, because their focus is still on the button they pressed. A live region is an element whose content changes are read out automatically, without moving focus.
\n<p id=\"basket-status\" role=\"status\"></p>function addToBasket() {\n count += 1;\n basketStatus.textContent = `Ticket added. ${count} tickets in your basket.`;\n}Three rules make live regions reliable:
\nrole="status" (same as aria-live="polite") waits until the screen reader finishes its current sentence. role="alert" (assertive) interrupts. Reserve alerts for urgent, rare messages like a failed payment; an assertive “Ticket added” on every click is exhausting.ARIA’s states and roles become most powerful in custom widgets, where no HTML element exists at all. The next lesson builds three of them following the ARIA Authoring Practices Guide.
\n","toc":[{"id":"sec-1","text":"The first rule of ARIA","level":2},{"id":"sec-2","text":"Roles, properties and states","level":2},{"id":"sec-3","text":"Live regions: announcing changes","level":2}],"takeaways":["The first rule of ARIA is to use a native HTML element when one exists; ARIA changes what is announced, never how anything behaves.","ARIA comes in roles (what it is), properties (relationships and fixed traits) and states (values that change, which your script must keep in sync).","Never put aria-hidden=“true” on a focusable element or override the role of a native element that already has the right one.","A live region must already be in the DOM before its text changes; use role=“status” for polite updates and role=“alert” only for urgent ones."],"further":[{"title":"W3C: Using ARIA (the rules of ARIA use)","url":"https://www.w3.org/TR/using-aria/"},{"title":"MDN: ARIA live regions","url":"https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Guides/Live_regions"},{"title":"W3C APG: Read Me First","url":"https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/"}],"quiz":[{"q":"What does adding role="button" to a <span> change?
Ticketly shows “Ticket added. 2 tickets in your basket.” in this element after a click. Why do screen readers stay silent?
\nconst msg = document.createElement('p');\nmsg.setAttribute('role', 'status');\nmsg.textContent = 'Ticket added. 2 tickets in your basket.';\nbasket.append(msg);Which of these uses ARIA correctly?
","options":[{"text":"<button aria-pressed="false">Save to wishlist</button>, updated to “true” when saved","why":"Correct. A toggle button exposes its state with aria-pressed, and the script keeps it in sync, so users hear “Save to wishlist, toggle button, pressed”."},{"text":"<h2 role="button" onclick="toggle()">Refunds</h2>","why":"This replaces the heading role, so it vanishes from heading navigation, and the “button” still has no keyboard support."},{"text":"<a href="/faq" aria-hidden="true">FAQ</a>","why":"The link is still focusable but now has no name or role in the tree. Keyboard users land on a silent stop."},{"text":"<nav role="navigation">","why":"Not harmful, but redundant. The nav element already has the navigation role, so the attribute adds nothing."}],"answer":0},{"q":"The payment provider rejects a card at Ticketly’s checkout. Which live region role fits the message “Payment failed. Your card was declined.”?
","options":[{"text":"role="status"","why":"status waits politely until the screen reader finishes speaking. For a blocking failure the user must hear now, alert is the better fit."},{"text":"role="log"","why":"log is for sequences of messages such as chat history, where new entries are added at the end."},{"text":"role="alert"","why":"Correct. alert is assertive: it interrupts current speech, which is right for a rare, urgent message the user must act on."}],"answer":2}],"exercise":{"kind":"web","mode":"dom","starter":{"html":"\n\nFour small ARIA jobs on Ticketly’s pass card:
\naria-current="page".aria-pressed="false" and flip it on each click. Keep the label text unchanged.#basket-status a polite live region so “Ticket added…” is announced.aria-hidden="true", which leaves a silent Tab stop. Fix it without removing the button (you may change its text).aria-current="page" adds “current page” to the Tickets link announcement. The wishlist button keeps its label and exposes its state through aria-pressed, which the click handler keeps in sync; the CSS can style from the same attribute. role="status" on the existing, empty paragraph means each new message is read politely without moving focus. And the sticky button is visible and focusable again in the accessibility tree: a focusable element must never sit inside aria-hidden="true", because keyboard users reach it while screen readers stay silent.