Web Accessibility Cookbook

1Every element has a name, a role, a state

The book is a true cookbook (thirteen chapters of standalone recipes), but under the recipes sits one mental model, and that is the one to take away. A blind person does not see your button; their screen reader announces it, as three pieces of information: a name (the text read out), a role (what kind of thing it is) and a state (checked, open, disabled…).

<button aria-pressed="true">Favorite</button>
<!-- announced: "Favorite, button, pressed" -->
<!--            ^name     ^role   ^state -->

All of accessibility fits in that loop: for each component, ask "are its name, role and state correct and announced?". A clickable <div> has no role and no state: to a screen reader, it does not exist. That is why the first rule (idea 2) is to use the right HTML element, which provides those three for free. And as the preface says, accessibility "doesn't just touch on the disciplines of web development, it connects them": the recipe for one is usually the recipe for all.

2The first rule of ARIA: don't use ARIA

The spine of the whole book: reach for the native HTML element first, and only add ARIA when no element does the job. A real <button> already ships with a role, keyboard support and focus; a <div role="button"> makes you rebuild all of that by hand, and the WebAIM Million found 27.5% of sites get it wrong.

Every interactive element needs two things the book keeps coming back to: a role (what kind of thing it is) and an accessible name (the text a screen reader announces). Get those right with plain HTML and most of accessibility is already done.

3Takes you somewhere? Link. Does something? Button.

The single most useful rule in front-end, and Matuzović makes it a test: if it navigates, use <a>; if it triggers an action, use <button>. The two look interchangeable and behave nothing alike: a link is followed, a button is pressed, and screen readers announce them differently.

And whichever you pick, never strip the focus outline without replacing it, and label it for what it is: a linked image describes its destination, an icon button describes its action, never the picture.

4Respect the user's settings, don't override them

Browsers and operating systems already expose what people need:

• dark mode (prefers-color-scheme);
• reduced motion (prefers-reduced-motion);
• increased contrast and forced colors;
• a bigger base font.

The chapter on CSS is one long argument that ignoring those signals is disrespect, not neutrality.

The detail that sticks: the media query is prefers-reduced-motion, "not prefers-no-motion for a reason" (ch. 5). The point is to cut gratuitous movement, not to kill every animation. And CSS can quietly break meaning: list-style: none can strip a list's semantics in Safari, so you sometimes have to add role="list" back.

5Focus is the cursor for people without a mouse

For keyboard and screen-reader users, the focus ring is the pointer. Matuzović's line is blunt: "Removing focus indicators for keyboard users is like hiding the cursor for mouse users" (ch. 6). So you never delete the outline; you style it, ideally with :focus-visible, and you keep it visible in Forced Colors mode with a transparent outline trick.

Two more rules close the chapter. Reading order follows the DOM, so reordering with CSS order or flex-direction desynchronizes what's seen from what's read. And for modals, prefer the native <dialog> or the inert attribute over a hand-rolled focus trap.

6There are five ways to hide content, and they're opposites

"Hidden" is not one thing. Hiding visually is not hiding from a screen reader, and the two are often confused with painful results. The book lays out the trade-offs side by side.

For the common case (a show/hide section), the native <details> works without a line of JavaScript; the chapter weighs it honestly against a custom disclosure widget when you need consistent cross-browser behavior.

7Half the web's form fields have no label

The number that frames the chapter: per the WebAIM Million 2023, "45.9% of tested websites contained form elements with missing labels" (ch. 9), meaning no <label>, the HTML element that names a field. A visible label, tied to its field with for/id, is the one non-negotiable; everything else (hints, error messages, grouping) only reduces the effort on top of it.

The recipes are the ones you reuse forever:

• <fieldset> + <legend> for radio and checkbox groups;
• aria-describedby for hints and error messages;
• an error summary at the top that moves focus to itself on submit.

The placeholder-as-label, the book reminds you, is an anti-pattern: it vanishes the moment you type.

8Automated tests are a net, not a certificate

The closing chapter is a reality check. Tools like axe, Lighthouse and WAVE catch the mechanical errors, but not meaning. The difference is sharp:

<img src="chart.png">              <!-- axe CATCHES IT: missing alt, error -->
<img src="chart.png" alt="image">  <!-- axe SEES NOTHING: alt present…
                                          but "image" says nothing useful -->

"A perfect score doesn't mean your site is accessible" (ch. 13): the tool checks an alt exists, never that it actually describes the image. They're a starting net, not a finish line.

The most modern warning is about web components: the Shadow DOM's encapsulation breaks ID references, so a label in the light DOM can't point to an input in the shadow DOM. Worse, several popular auditors see nothing inside a shadow root at all. Build accessible components, then test them with a real screen reader.