Accessibility

What it means for a web client

The load-bearing fact is that assistive technology does not read your pixels. Screen readers, voice control and switch devices consume the accessibility tree, a parallel structure the browser derives from the DOM. Every element contributes a role (what it is), a name (what it is called) and a state (what it is doing). Semantic HTML fills in all three for free. A <div> with a click handler contributes none of them: no role, no name, no keyboard behavior. For a keyboard or screen reader user, that button does not exist.

This is why the course treats accessibility as a matter of going with the grain of the platform. The browser already ships the machinery: the accessibility tree, focus management, native keyboard behavior, and media queries that report the user's preferences. Your job is mostly not to break it. Divitis is not a style crime; it is disconnecting people from that machinery. The first rule of ARIA follows directly: do not use ARIA when an HTML element already does the job.

Accessibility sits on the third rung of the Life of a Page Load ladder, after availability and before internationalization and usability. The boundary matters. Accessibility covers the mechanics of perception and operation; whether the labeled, reachable checkout makes sense as a task is usability, the next question up. And the people it serves are not a small special audience. A broken wrist, a phone in sunlight, a loud train: temporary and situational limits mean you are building for everyone on a bad day, including a future you.

Where it lives in each layer

Structure

Markup is where accessibility is won or lost. Landmarks (<header>, <nav>, <main>), one <h1> and a real heading outline give a screen reader user a page they can skim. Real <button> and <a href> elements are focusable and answer Enter and Space natively. Visible <label for> elements name every field. Informative images need alt text that carries the same information; decorative ones need alt="". One misplaced aria-hidden="true" removes a whole menu from the tree while every screenshot still looks perfect.

Presentation

CSS decides whether people can see and track the page. Size text in rem so it follows the user's default font size, never block zoom, and let layouts reflow rather than scroll sideways. WCAG asks for 4.5:1 contrast on normal text and 3:1 on large text and controls. Color may reinforce meaning but never carry it alone. Style focus with :focus-visible instead of removing it with outline: none. Gate animation behind prefers-reduced-motion, and reserve space so content does not shift under a finger mid-tap. Media needs captions and transcripts.

Interaction

Scripts must keep keyboard parity and keep the tree honest. Listen for submit on the form, not click on the button, or you miss the keyboard path. Write results into an <output> with aria-live so they are announced, not just painted. Prefer a native element over a hand-built widget: rebuilding <progress> or <details> as a component throws away behavior you then have to recreate. Inside a shadow root, focus and names do not route themselves; use delegatesFocus and ElementInternals, and test with a screen reader.

Delivery

How data reaches the page changes what assistive technology hears. A full-page postback resets focus to the top and announces a whole new document; a keyboard user who had tabbed to the eleventh control starts over. A fetch that swaps a list in place announces nothing at all. Partial updates keep focus and state, but they make you responsible for moving focus and announcing the change, because no new document arrived to do it for you.

Where the course teaches it

• Accessibility, rung 3 of The Life of a Page Load: the failure catalog by ability, the checklist, and the change-bodies exercise on the broken and fixed stores.
• Who Fell Off the Ladder? (film): a screen reader user and a keyboard user each lose the store to one markup decision.
• Usability, rung 5: where perception and operation end and task sense begins.
• Parsing HTML into the DOM: the accessibility tree as a child of the DOM, and why the DOM is the product for blind users and bots.
• Style, layout, paint, composite: layout shift as accessibility work as much as performance work.
• Forms: events that do work: why submit catches the keyboard path that click misses.
• Component basics: hand-built widgets that lose what native elements give you free.
• Shadow DOM considerations: what the boundary costs assistive tooling.
• Form-associated elements: routing focus and accessible names into a shadow root.
• The postback problem: what a full navigation does to focus and to screen reader users.
• Ajax appears: why an in-place update announces nothing unless you make it.
• Who is visiting? (tool): see which visitors, screen reader and keyboard users among them, your choices lock out.

Check your own page

1. Put the mouse away and Tab through the page. Every control should be reachable, in a sensible order, with a visible focus ring, and a skip link should be the first stop.
2. Turn on a screen reader (VoiceOver, Narrator or NVDA) and pull up the headings and landmarks lists. You should find one <h1>, a logical outline, and your navigation.
3. Search your markup for onclick on non-interactive elements, positive tabindex values, aria-hidden, and outline: none. Justify each one or remove it.
4. Check every <img>: informative images carry their information in alt; decorative ones have alt="".
5. In DevTools, use the Rendering panel to emulate vision deficiencies and prefers-reduced-motion: reduce. Nothing should depend on color alone, and nothing should keep moving.
6. Set the browser's default font size to Very Large and zoom to 400%. Text should grow and the layout should reflow.
7. Trigger every script-driven update and ask what a screen reader user was told and where focus ended up.