An intermediate course for software developers, UI developers and product designers who already know HTML and CSS. You start with the people accessibility serves and how WCAG 2.2 turns their needs into testable success criteria, then make widgets keyboard operable with visible focus and give every control an accessible name, using ARIA only where HTML falls short. Next you build responsive interfaces: fluid type and spacing with clamp() and design tokens, card grids and container queries that reflow at any width, and images that load the right size and format. Finally you test like a professional: automated audits with Lighthouse and axe, a repeatable screen reader script with NVDA or VoiceOver, and a hands-on fix of a broken page. Every lesson has a reading, free videos and a quiz, and most have an in-browser exercise that checks your work.

Build interfaces that work for everyone on every screen: WCAG 2.2, keyboard and ARIA, fluid layouts, responsive images and real audits.

Accessible & Responsive Interfaces

## Why this matters

Accessibility means people with disabilities can perceive, understand, navigate and interact with what you build. It is not a niche. The World Health Organization estimates that about 1.3 billion people, roughly one in six, live with a significant disability, and almost everyone has a temporary or situational limitation at some point: a broken wrist, a bright screen in the sun, a noisy train, an aging parent's eyesight. When an interface is accessible, it usually works better for everyone.

It is also part of the job. Software developers, UI developers and product designers are expected to ship interfaces that meet the Web Content Accessibility Guidelines (WCAG), and many organisations are legally required to. You will meet WCAG properly in the next lesson; this one is about the people.

## Who uses the web differently

The W3C's [How People with Disabilities Use the Web](https://www.w3.org/WAI/people-use-web/) groups needs into a few broad areas. Real people often have more than one.

- **Visual.** Blindness, low vision and colour vision deficiency. Blind users rely on a **screen reader**, which speaks the page (or sends it to a refreshable **braille display**). Low-vision users zoom to 200 or 400 percent, use screen magnifiers, increase text spacing or switch to high-contrast modes. About 1 in 12 men has some form of colour vision deficiency, so colour alone cannot carry meaning.
- **Auditory.** Deaf and hard-of-hearing users need **captions** for video and **transcripts** for audio. Some are fluent in a sign language and read written English as a second language, so plain wording helps.
- **Motor and physical.** Tremors, paralysis, arthritis, missing limbs or repetitive strain injury. People may use only a **keyboard**, a **switch** (one or two buttons that step through options), **voice control** ("click Submit"), a head pointer or eye tracking. Small click targets and drag-only interactions shut them out.
- **Cognitive, learning and neurological.** Dyslexia, ADHD, memory loss, autism, epilepsy and more. Clear language, predictable layouts, no surprise time limits, and no flashing content (which can trigger seizures) all matter.
- **Speech.** Interfaces that only accept voice input exclude people who cannot speak clearly.

## Assistive technology in practice

Assistive technology sits between the person and your page. It does not see pixels; it reads the browser's **accessibility tree**, a simplified version of the DOM that exposes each element's **role** (button, link, heading), **name** ("Search"), and **state** (checked, expanded). That is why semantic HTML matters so much:

```html

<button type="button">Save draft</button>


<div class="btn" onclick="save()">Save draft</div>
```

Both look identical once styled. Only the first one is usable without a mouse.

Common tools you should know by name:

| Tool | Who uses it | Platform |
|---|---|---|
| NVDA (free), JAWS | Blind and low-vision users | Windows |
| VoiceOver | Blind and low-vision users | macOS, iOS (built in) |
| TalkBack | Blind and low-vision users | Android (built in) |
| Screen magnifiers, browser zoom | Low-vision users | All |
| Voice Control, Dragon | Motor disabilities | macOS/iOS, Windows |
| Switch access | Severe motor disabilities | All major OSs |

## Worked example: one product page, five people

Imagine a shoe shop's product page, and walk it through five visitors.

1. **Amira is blind and uses NVDA.** She presses `H` to jump between headings. If the product name is a styled `<div>`, there is nothing to jump to. If the size picker is a set of coloured squares with no text, she hears "clickable, clickable, clickable".
2. **Ben has a tremor and uses only the keyboard.** He presses `Tab` to move. If the "Add to bag" control is a `<div>`, Tab skips it and he cannot buy anything.
3. **Chen has low vision and zooms to 400 percent.** If the layout does not reflow, he has to scroll sideways on every line.
4. **Dana is colour-blind.** "Out of stock sizes are shown in red" means nothing to her unless the size is also crossed out or labelled.
5. **Eli is Deaf.** The product video explains the fit, but has no captions.

None of these fixes is exotic: headings, real buttons, text labels, a layout that reflows, and captions. That is most of accessibility.

## The social model

Disability advocates describe a **social model**: a person is disabled by barriers in the environment, not only by their body. A blind person is not "unable to shop"; the site with unlabelled buttons is what blocks them. As a builder, you control those barriers. That framing is useful because it turns accessibility from charity into engineering: find the barrier, remove it, test it.

## Common mistakes

- **Treating accessibility as a final checklist.** Retrofitting a finished design costs far more than choosing a real `<button>` on day one.
- **Assuming "screen reader user" means everyone.** Keyboard-only, zoom, voice and cognitive needs are just as common.
- **Building an "accessible version".** Separate text-only sites fall out of date. Make the one site work.
- **Relying on overlays.** Third-party "accessibility overlay" widgets do not fix inaccessible code, and many disabled users actively avoid them.
- **Never meeting users.** Watching a real assistive technology user for ten minutes teaches more than hours of reading.

## Quick recap

- About one in six people has a significant disability, and situational limits affect everyone.
- Needs fall into visual, auditory, motor, cognitive and speech areas.
- Assistive technology reads the accessibility tree: role, name and state.
- Native HTML elements give you most of that for free.
- Further reading: [W3C WAI: Introduction to Web Accessibility](https://www.w3.org/WAI/fundamentals/accessibility-intro/).

## Try it

Open the **Do** tab for a short quiz on who accessibility serves.

Meet the people who use the web differently and the assistive technology they rely on.

Who accessibility serves

Introduction to Web Accessibility and W3C Standards

Web Accessibility Perspectives - Compilation of 10 Topics/Videos

## Why this matters

"Make it accessible" is too vague to build or test. The **Web Content Accessibility Guidelines (WCAG)**, published by the W3C, turn it into testable requirements. Most accessibility laws and procurement rules point at WCAG, most audits report against it, and job descriptions for front-end and design roles name it. Learning to translate a WCAG criterion into a concrete page fix is a core skill.

## How WCAG is organised

WCAG has four layers:

1. **Principles (POUR):** content must be **Perceivable**, **Operable**, **Understandable** and **Robust**.
2. **Guidelines:** 13 goals under the principles, such as 1.4 Distinguishable or 2.1 Keyboard Accessible.
3. **Success criteria:** the testable rules, numbered like `1.4.3 Contrast (Minimum)`. Each has a level.
4. **Techniques and Understanding documents:** W3C's explanations of intent and known ways to pass or fail.

Levels are **A** (minimum), **AA** (the usual target) and **AAA** (enhanced, not expected site-wide). When a contract or law says "WCAG 2.2 AA", it means every A and AA criterion.

**Versions.** WCAG 2.0 (2008), 2.1 (2018) and 2.2 (October 2023) are backwards compatible: a page that meets 2.2 also meets 2.1 and 2.0, with one exception. 2.2 removed 4.1.1 Parsing as obsolete. WCAG 3 is a separate, early-stage draft and is not a current standard. Checked on 2026-10-23: see [WCAG 2 Overview](https://www.w3.org/WAI/standards-guidelines/wcag/).

## POUR mapped to fixes

| Principle | Ask yourself | Example criteria (level) | Typical fix |
|---|---|---|---|
| Perceivable | Can everyone get the information through at least one sense? | 1.1.1 Non-text Content (A), 1.2.2 Captions (A), 1.3.1 Info and Relationships (A), 1.4.1 Use of Color (A), 1.4.3 Contrast (AA), 1.4.10 Reflow (AA) | Alt text, captions, real headings and lists, text plus colour, 4.5:1 contrast, layouts that work at 320 CSS px wide |
| Operable | Can everyone use every control? | 2.1.1 Keyboard (A), 2.1.2 No Keyboard Trap (A), 2.4.1 Bypass Blocks (A), 2.4.3 Focus Order (A), 2.4.7 Focus Visible (AA), 2.5.8 Target Size (Minimum) (AA) | Native buttons, a skip link, logical tab order, visible focus styles, targets at least 24 by 24 CSS px |
| Understandable | Is it predictable and clear? | 3.1.1 Language of Page (A), 3.2.2 On Input (A), 3.3.1 Error Identification (A), 3.3.2 Labels or Instructions (A) | `lang` on `<html>`, no surprise navigation on change, text error messages, visible labels |
| Robust | Does it work with assistive technology? | 4.1.2 Name, Role, Value (A), 4.1.3 Status Messages (AA) | Native elements or correct ARIA, live regions for "Saved" messages |

## Numbers worth memorising

- **Contrast (1.4.3, AA):** 4.5:1 for normal text; 3:1 for large text (at least 24 CSS px, or 18.66 px bold).
- **Non-text contrast (1.4.11, AA):** 3:1 for control borders, focus indicators and meaningful icons.
- **Resize text (1.4.4, AA):** text can be zoomed to 200 percent without losing content.
- **Reflow (1.4.10, AA):** no two-way scrolling at 320 CSS px wide (a 1280 px window at 400 percent zoom).
- **Target size (2.5.8, AA, new in 2.2):** pointer targets at least 24 by 24 CSS px, or enough spacing around smaller ones.

## What WCAG 2.2 added

Nine new criteria, six of them at A or AA ([What's New in WCAG 2.2](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)):

- **2.4.11 Focus Not Obscured (Minimum), AA:** a sticky header or cookie banner must not completely hide the focused element.
- **2.5.7 Dragging Movements, AA:** anything done by dragging also works with single clicks (for example, arrow buttons on a sortable list).
- **2.5.8 Target Size (Minimum), AA.**
- **3.2.6 Consistent Help, A:** help links or contact details appear in the same place on each page.
- **3.3.7 Redundant Entry, A:** do not make people retype information they already gave in the same process.
- **3.3.8 Accessible Authentication (Minimum), AA:** no cognitive test such as remembering or transcribing a code to log in, unless there is an alternative; allow paste and password managers.

## Worked example: auditing a sign-up form against POUR

A form has grey placeholder text instead of labels, a red border as the only error signal, a "Next" button made from a `<div>`, and a CAPTCHA that asks you to type distorted letters.

- **Perceivable:** placeholder-only fields fail 3.3.2 (and the light grey often fails 1.4.3). Red-only errors fail 1.4.1. Fix: visible `<label>` elements and an error message in text.
- **Operable:** the `<div>` fails 2.1.1. Fix: `<button>`.
- **Understandable:** "Invalid input" does not say what is wrong. Fix: "Enter an email address like name@example.com" (3.3.1, 3.3.3).
- **Robust:** the custom button has no role (4.1.2). The native button fixes it.
- **2.2 addition:** the text CAPTCHA is a cognitive function test (3.3.8). Offer an alternative.

Write findings as criterion, location, problem and fix. That format is what audit reports and bug trackers expect.

## The law, briefly

Many laws reference WCAG: the US Section 508 standards (WCAG 2.0 AA), the European standard EN 301 549 used by the European Accessibility Act (applying from June 2025), and courts and regulators under the ADA in the US. Requirements and versions differ by country and keep changing, so check the W3C's [Web Accessibility Laws and Policies](https://www.w3.org/WAI/policies/) list rather than memorising them. Checked on 2026-10-23. You are not expected to give legal advice; you are expected to build to WCAG AA.

## Common mistakes

- **Treating AAA as the target for everything.** Some AAA criteria cannot be met for all content. Target AA and use AAA where it is easy.
- **Quoting a number without its criterion.** Say "fails 1.4.3, measured 3.2:1", not "contrast is bad".
- **Assuming automated tools prove conformance.** They catch only a portion; many criteria need human judgement.
- **Ignoring states.** Hover, focus, error and disabled states all need to meet the rules too.

## Quick recap

- POUR: Perceivable, Operable, Understandable, Robust.
- Levels A, AA, AAA; AA is the normal target. WCAG 2.2 is the current version.
- Key numbers: 4.5:1 and 3:1 contrast, 200 percent resize, 320 px reflow, 24 px targets.
- Bookmark the [WCAG 2.2 Quick Reference](https://www.w3.org/WAI/WCAG22/quickref/) and its Understanding pages.

## Try it

Open the **Do** tab and map problems to POUR principles and success criteria.


Map the POUR principles and WCAG 2.2 success criteria to concrete page fixes.

WCAG in practice

WCAG for beginners - What are the Web Content Accessibility Guidelines? - Web Accessibility

WCAG 2.2 is Officially Released: Quick Summary for all 6 AA Success Criteria

## Why this matters

Everything a mouse can do, a keyboard must do too (WCAG 2.1.1, Level A). Keyboard access is not only for blind users: people with tremors, repetitive strain, temporary injuries, switch devices and voice control all depend on the same focus system. Power users love it too. And if a control is not keyboard operable, screen readers usually cannot operate it either.

## How focus works

Only one element has **focus** at a time; key presses go to it. `Tab` moves focus forward, `Shift+Tab` back. Native interactive elements are focusable and respond to the right keys for free:

| Element | Keys |
|---|---|
| `<a href>` | Enter follows the link |
| `<button>` | Enter and Space activate |
| `<input type="checkbox">` | Space toggles |
| Radio group | Arrow keys move between options |
| `<select>` | Arrow keys change, Enter or Space opens |
| `<details>`/`<summary>` | Enter and Space toggle |

**Focus order** follows the DOM order (2.4.3). If CSS reorders things visually (`order`, `flex-direction: row-reverse`, grid placement), the tab order no longer matches what people see. Fix the source order instead.

## tabindex: three values to know

- `tabindex="0"` makes a non-interactive element focusable in normal order. Use it rarely, for custom widgets or scrollable regions.
- `tabindex="-1"` makes an element focusable by script (`el.focus()`) but not by Tab. Use it for headings you move focus to or the target of a skip link.
- `tabindex="1"` or higher jumps the element ahead of everything else. **Never use positive values**; they create a confusing order that is hard to maintain.

## Make focus visible

WCAG 2.4.7 (AA) requires a visible focus indicator. The most common failure in the wild is one line of CSS:

```css
/* Removes the only clue keyboard users have. Do not do this. */
:focus { outline: none; }
```

Use `:focus-visible` instead. Browsers apply it when focus should be shown (keyboard navigation) and usually not after a mouse click:

```css
:focus-visible {
  outline: 3px solid #1a5fb4;
  outline-offset: 2px;
}
```

Make the indicator contrast at least 3:1 with the background (1.4.11), and keep it from being hidden behind sticky headers (2.4.11). `scroll-padding-top` on `html` helps when you have a fixed header.

## Skip links

Repeated headers make keyboard users press Tab dozens of times on every page. A **skip link** is the first focusable element and jumps to the main content (2.4.1 Bypass Blocks):

```html
<a class="skip-link" href="#main">Skip to main content</a>
...
<main id="main" tabindex="-1">...</main>
```

```css
.skip-link { position: absolute; left: -9999px; }
.skip-link:focus { left: 1rem; top: 1rem; }
```

## Worked example: a disclosure widget

A common FAQ pattern hides an answer until the question is clicked. Here is the broken version:

```html
<div class="question" onclick="toggle()">What is your returns policy?</div>
<div class="answer" style="display:none">30 days, free.</div>
```

Problems: the div is not focusable, Enter and Space do nothing, and a screen reader cannot tell it opens anything. The fix uses a button and two attributes from the [WAI-ARIA Authoring Practices disclosure pattern](https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/):

```html
<button type="button" id="faq-toggle" aria-expanded="false" aria-controls="faq-answer">
  What is your returns policy?
</button>
<div id="faq-answer" hidden>30 days, free.</div>

<script>
  const btn = document.getElementById('faq-toggle');
  const panel = document.getElementById('faq-answer');
  btn.addEventListener('click', () => {
    const open = btn.getAttribute('aria-expanded') === 'true';
    btn.setAttribute('aria-expanded', String(!open));
    panel.hidden = open;
  });
</script>
```

- The `<button>` is focusable and fires `click` on Enter and Space, so one handler covers mouse, keyboard, touch and voice.
- `aria-expanded` tells assistive technology whether it is open ("collapsed" or "expanded" is announced).
- The `hidden` attribute removes the closed panel from view and from the accessibility tree.

For a simple case, `<details><summary>` does all of this with no script. Reach for the button version when you need custom styling or behaviour.

## Managing focus in dynamic UI

When a dialog opens, move focus into it; when it closes, return focus to the button that opened it. When content is deleted, move focus somewhere sensible instead of losing it to `<body>`. Do not trap focus unless the UI is truly modal, and always provide a way out (Esc) so you never fail 2.1.2 No Keyboard Trap. The native `<dialog>` element with `showModal()` handles much of this for you.

## How to test

Put the mouse away. Starting from the address bar, press Tab through the whole page and check: can you see where focus is at every step? Is the order logical? Can you operate every control with Enter, Space, arrows and Esc? Can you get out of every widget? This takes five minutes and finds real bugs every time.

## Common mistakes

- `outline: none` with no replacement.
- Click handlers on `div` or `span` instead of `button`.
- Positive `tabindex` values.
- Visual reordering with CSS that scrambles the tab order.
- Hover-only menus that never open with the keyboard.

## Quick recap

- Every control must work by keyboard; native elements do this for free.
- Keep focus order logical and focus always visible with `:focus-visible`.
- Add a skip link; use `tabindex="-1"` for script focus targets, never positive values.
- Disclosure widgets: `<button aria-expanded aria-controls>` plus `hidden`.

## Try it

Open the **Do** tab and make a broken FAQ widget fully keyboard operable.


Make a widget fully keyboard operable with native buttons, visible focus and a skip link.

Keyboard and focus

What is Focus? -- A11ycasts #03

Quick guide to CSS focus states

## Why this matters

Every control needs an **accessible name**: the text a screen reader announces and the words a voice control user says ("click Search"). WCAG 4.1.2 Name, Role, Value and 1.3.1 Info and Relationships (both Level A) require it, and missing names are among the most common failures automated tools find. ARIA (Accessible Rich Internet Applications) is the toolkit for filling gaps HTML cannot, but used carelessly it makes pages worse.

## Where accessible names come from

The browser computes a name for each element in a fixed priority order (simplified):

1. `aria-labelledby` (points at other elements' ids; their text becomes the name)
2. `aria-label` (a string)
3. The native label: `<label>` for inputs, `alt` for images, `<caption>` for tables, `<legend>` for fieldsets
4. The element's text content (for buttons, links and headings)
5. `title` (a weak last resort; avoid relying on it)

You can see the result in Chrome or Firefox DevTools: Inspect an element and open the **Accessibility** pane.

## Labels for form fields

Always start with a visible `<label>`:

```html
<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email" required aria-describedby="email-hint">
<p id="email-hint">We only use this to send your receipt.</p>
```

- `for`/`id` links the label, so clicking the label focuses the input and the name is "Email address".
- **Placeholders are not labels.** They disappear when you type, are often low contrast, and are not reliably announced.
- `aria-describedby` adds a **description**, announced after the name: perfect for hints and error messages.
- `required` is native and exposed to assistive technology; you do not need `aria-required` as well.
- `autocomplete` helps everyone and supports WCAG 1.3.5 Identify Input Purpose (AA).

Group related controls such as radio buttons with `<fieldset>` and `<legend>`.

## Icon-only buttons

A magnifying-glass button with only an SVG has no name; a screen reader says "button". Two good fixes:

```html

<button type="submit" aria-label="Search">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>


<button type="submit">
  <svg aria-hidden="true" focusable="false">...</svg>
  <span class="visually-hidden">Search</span>
</button>
```

If a control has visible text, the accessible name should contain that text (WCAG 2.5.3 Label in Name), so voice users can say what they see. Do not put `aria-label="Submit form"` on a button that reads "Send".

## Images

- Informative image: `alt` describes what it conveys (`alt="Acme Tools logo"`, not `alt="image"`).
- Decorative image: `alt=""` so screen readers skip it. Leaving `alt` out entirely makes some screen readers read the file name.
- Image inside a link: the alt describes the link's destination.

The W3C's [alt decision tree](https://www.w3.org/WAI/tutorials/images/decision-tree/) is worth bookmarking.

## The rules of ARIA

The W3C's [Using ARIA](https://www.w3.org/TR/using-aria/) note sets out five rules. The first is the one people quote:

1. **If a native HTML element has the semantics and behaviour you need, use it** instead of re-purposing an element and adding ARIA.
2. Do not change native semantics unless you really have to (no `<h2 role="tab">`; wrap or restructure instead).
3. All interactive ARIA controls must be keyboard operable.
4. Do not use `role="presentation"` or `aria-hidden="true"` on a focusable element.
5. All interactive elements must have an accessible name.

ARIA only changes what assistive technology is **told**. It adds no behaviour. `<div role="button">` announces "button" but still cannot be focused or activated with Enter and Space unless you add `tabindex="0"` and key handlers yourself. A real `<button>` does all of that already. This is why audits regularly find that pages with ARIA have more errors than pages without it.

## ARIA you will actually use

| Attribute | Use it for |
|---|---|
| `aria-label`, `aria-labelledby` | Naming controls with no visible label, or landmarks (`<nav aria-label="Breadcrumb">`) |
| `aria-describedby` | Hints and error messages |
| `aria-expanded`, `aria-controls` | Disclosures, menus, accordions |
| `aria-current="page"` | The current link in navigation |
| `aria-hidden="true"` | Hiding decorative icons from assistive technology |
| `aria-live="polite"`, `role="status"` | Announcing "Saved" or "3 results" without moving focus (4.1.3) |
| `aria-invalid="true"` | Marking a field with an error |

For complex widgets (tabs, comboboxes, menus, tree views), follow the [ARIA Authoring Practices Guide](https://www.w3.org/WAI/ARIA/apg/) and test with real screen readers; the patterns include required keyboard behaviour, not just attributes.

## Worked example: fixing a newsletter form

Before: `<input placeholder="Email">`, a hint in a `<small>` floating nearby, a `<div role="button" onclick="subscribe()">Subscribe</div>`, and a decorative swoosh image with no alt.

After: a visible `<label for="email">`, `aria-describedby` linking the hint, a real `<button type="button">Subscribe</button>` (the `role` attribute removed), and `alt=""` on the swoosh. Four changes, every one of them plain HTML except `aria-describedby`.

## Common mistakes

- Placeholder text as the only label.
- `aria-label` on a `<div>` or `<span>` with no role: many screen readers ignore it there.
- Redundant ARIA: `<button role="button">`, `<nav role="navigation">`. Harmless at best, noise at worst.
- `aria-hidden="true"` on something that can still receive focus.
- Names that do not match the visible text.

## Quick recap

- Every control needs an accessible name; check it in the DevTools Accessibility pane.
- Prefer visible `<label>`s, button text and `alt`; use `aria-label`/`aria-labelledby` when there is no visible text.
- `aria-describedby` for hints and errors.
- First rule of ARIA: use native HTML. ARIA changes announcements, not behaviour.

## Try it

Open the **Do** tab and fix the labels and ARIA in a newsletter form.

Give every control an accessible name and use ARIA only when HTML cannot do the job.

Labels and ARIA

Intro to ARIA -- A11ycasts #13

The art of labeling -- A11ycasts #12

Who accessibility serves, how WCAG 2.2 turns it into testable rules, and how to make controls keyboard operable and correctly labelled.

Accessibility Essentials

## Why this matters

Your page will be read on a 320 px phone, a 1440 px laptop and a 4K monitor, by people who have set their browser's default text size larger, or who zoom to 200 or 400 percent. Fixed pixel sizes fight all of that. Relative units and `clamp()` let type and spacing scale smoothly with both the screen and the reader's own settings, which is good design and a WCAG requirement (1.4.4 Resize Text and 1.4.10 Reflow, both AA).

## Relative units, briefly

| Unit | Relative to | Good for |
|---|---|---|
| `rem` | The root (`html`) font size, 16 px by default | Font sizes, spacing, breakpoints |
| `em` | The current element's font size | Padding on buttons that should grow with their text |
| `ch` | The width of the "0" character | Line length (`max-width: 65ch`) |
| `%` | The parent's size | Widths inside a container |
| `vw` / `vh` | 1 percent of the viewport width / height | The *fluid part* of a `clamp()` |
| `dvh`, `svh`, `lvh` | Dynamic, small and large viewport heights | Full-height sections on mobile, where browser toolbars come and go |

The most important rule: **never set the root font size in pixels.** `html { font-size: 16px; }` overrides the reader's browser setting. If someone has chosen 20 px default text because of low vision, you just took it away. Leave the root alone, or use a percentage (`font-size: 100%`), and size everything else in `rem`.

## clamp(): fluid with limits

`clamp(MIN, PREFERRED, MAX)` returns the preferred value, but never less than MIN or more than MAX:

```css
h1 {
  font-size: clamp(2rem, 1.5rem + 2.5vw, 3.5rem);
}
```

- On a narrow phone, `1.5rem + 2.5vw` is small, so the heading stops at `2rem` (32 px by default).
- As the window grows, the `vw` part grows, and the heading scales smoothly.
- On a wide screen it stops at `3.5rem`.

Why `1.5rem + 2.5vw` and not just `5vw`? Because viewport units **do not respond to text zoom**. With pure `vw`, a user pressing Ctrl and + sees the layout shift but the heading stays the same size, which can fail 1.4.4. Mixing a `rem` term into the preferred value keeps it zoomable. Keep the MAX no more than about 2.5 times the MIN so 200 percent zoom still makes a real difference.

`min()` and `max()` are the one-sided versions: `width: min(100%, 60rem)` means "fill the space, but never wider than 60rem".

## Fluid spacing with tokens

Spacing should scale too, or a big heading ends up cramped on a laptop and enormous gaps eat a phone screen. Define a small set of spacing **tokens** as custom properties, then use only those:

```css
:root {
  --space-s: clamp(0.75rem, 0.7rem + 0.25vw, 1rem);
  --space-m: clamp(1rem, 0.9rem + 0.5vw, 1.5rem);
  --space-l: clamp(1.5rem, 1.2rem + 1.5vw, 3rem);
}

.card { padding: var(--space-m); }
.stack > * + * { margin-block-start: var(--space-s); }
```

Tokens keep a design consistent and make changes a one-line edit. Design systems call these "design tokens", and they are often generated from the same values designers use in Figma. Tools such as the free Utopia calculator (utopia.fyi) produce matching type and space scales for you.

## Readable line length

Long lines are hard to track back to the start of the next line, especially for people with dyslexia or low vision. Limit body text to roughly 45 to 75 characters:

```css
.prose p { max-width: 65ch; }
body { line-height: 1.5; }
```

`line-height` without a unit (1.5) scales with the font size. A unit-less value is also what WCAG 1.4.12 Text Spacing expects users to be able to override without breaking the layout, so avoid fixed heights on text containers.

## Worked example: converting a fixed design

A designer hands you a desktop mock-up: 48 px heading, 18 px body, 24 px card padding, 960 px content width. A fixed translation would be:

```css
html { font-size: 16px; }
h1 { font-size: 48px; }
.card { padding: 24px; width: 960px; }
```

A fluid, accessible translation:

```css
h1 { font-size: clamp(2rem, 1.5rem + 2.5vw, 3rem); }  /* 32 px to 48 px */
body { font-size: clamp(1rem, 0.95rem + 0.25vw, 1.125rem); line-height: 1.5; } /* 16 to 18 */
.card { padding: var(--space-m); }
.container { width: min(100% - 2rem, 60rem); margin-inline: auto; }
```

The desktop result is the same as the mock-up. The phone version is no longer squeezed, and every size follows the reader's preferences.

## Common mistakes

- Setting `html { font-size: 62.5%; }` or a pixel value to make "1rem = 10px". It still works with user settings if it is a percentage, but it confuses teams; prefer the default.
- Pure `vw` font sizes, which ignore zoom.
- A `clamp()` with MIN larger than MAX (MIN wins, silently).
- Fixed `height` on text boxes, which clips text when users increase spacing.
- Too many one-off sizes instead of a token scale.

## Quick recap

- Size type and spacing in `rem`; never fix the root font size in px.
- `clamp(min, rem + vw, max)` gives fluid sizes that still zoom.
- Put spacing in a few custom-property tokens.
- Cap paragraphs at about `65ch` and use a unit-less `line-height`.
- Reference: [MDN: clamp()](https://developer.mozilla.org/en-US/docs/Web/CSS/clamp) and [WCAG Understanding 1.4.4 Resize Text](https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html).

## Try it

Open the **Do** tab and convert a fixed-pixel page to fluid type and spacing.


Use rem, clamp() and spacing tokens so type and space scale with the screen and the reader's settings.

Fluid type and spacing

Simple solutions to responsive typography

min(), max(), and clamp() are CSS magic!

## Why this matters

A layout that only works at the width it was designed for breaks for most visitors: phones, tablets, split-screen windows and anyone zoomed to 400 percent. WCAG 1.4.10 Reflow (AA) requires that content works at 320 CSS px wide without horizontal scrolling (except for things like maps and data tables that genuinely need two dimensions). Modern CSS can do most of this with no media queries at all.

## Mobile-first, then let content decide

Start with a single column, which works on any screen, and add complexity only where there is room. Instead of guessing device widths ("iPhone", "iPad"), let the **content** decide: add a breakpoint when the layout starts to look wrong. Write breakpoints in `em` or `rem` so they also respond to zoom:

```css
.page { display: grid; gap: 1rem; }
@media (min-width: 48em) {
  .page { grid-template-columns: 16rem 1fr; }  /* sidebar appears when there is room */
}
```

## Pattern 1: the auto-fit card grid

This one line creates as many columns as fit, each at least 15rem wide, sharing extra space equally:

```css
.cards {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(15rem, 100%), 1fr));
  gap: 1rem;
}
```

Read it inside out:

- `minmax(15rem, 1fr)`: each column is at least 15rem and at most an equal share.
- `min(15rem, 100%)`: on a screen narrower than 15rem (or at high zoom), the minimum becomes 100 percent instead, so the card never overflows. Without this guard, a 320 px screen with a 15rem (240 px) minimum is fine, but larger minimums cause sideways scrolling.
- `auto-fit` vs `auto-fill`: both create as many tracks as fit. With few items, `auto-fit` collapses empty tracks so items stretch; `auto-fill` keeps the empty tracks.

No media query is needed: the browser reflows from one column to four as space allows. Kevin Powell and others call these "intrinsic" or "breakpoint-free" layouts.

## Pattern 2: wrapping rows with Flexbox

For a row of navigation links, tags or buttons:

```css
.site-nav ul {
  display: flex;
  flex-wrap: wrap;
  gap: 0.5rem 1rem;
  list-style: none;
  padding: 0;
}
```

`flex-wrap: wrap` lets items move to a new line instead of overflowing. `gap` spaces them evenly without margin hacks.

## Pattern 3: the sidebar that drops below

```css
.with-sidebar { display: flex; flex-wrap: wrap; gap: 1rem; }
.with-sidebar > aside { flex: 1 1 15rem; }
.with-sidebar > main  { flex: 999 1 30rem; }
```

The main area grows much faster, and when there is not room for 15rem plus 30rem the sidebar wraps underneath. Again, no breakpoint.

## Pattern 4: container queries

Media queries ask "how wide is the window?". A card in a narrow sidebar and the same card in a wide main column need different layouts, even though the window is the same. **Container queries** ask "how wide is my container?" and are supported in all current browsers:

```css
.card-wrap { container-type: inline-size; }

.card { display: grid; gap: 0.5rem; }
@container (min-width: 28rem) {
  .card { grid-template-columns: 8rem 1fr; }  /* image beside text when the card is wide */
}
```

`container-type: inline-size` makes the element a query container for its width. Components that adapt to their own space are much easier to reuse in a design system.

## Worked example: fixing a fixed-width card row

The broken version:

```css
.cards { display: flex; }
.card  { width: 300px; flex-shrink: 0; }
```

Four cards need 1200 px. On a phone, three of them hang off the right edge, forcing sideways scrolling and failing Reflow. The fix replaces both rules with the auto-fit grid above and removes the fixed width. Test by dragging the window narrower, then by zooming to 400 percent at 1280 px wide: the cards should stack into one column with no horizontal scrollbar.

## Accessibility and layout

- **Keep DOM order meaningful.** Grid placement and `order` can move items visually without changing the reading and tab order. Screen reader and keyboard users get the DOM order.
- **Avoid fixed heights.** Content grows when text is zoomed or spaced (1.4.12); let height be automatic.
- **Watch sticky elements.** A sticky header that is fine at 100 percent can cover half the screen at 400 percent zoom. Consider removing stickiness on short viewports with `@media (max-height: 30em)`.

## Common mistakes

- Breakpoints in `px` tied to specific devices.
- `width` in pixels on flexible items.
- Forgetting the `min(…, 100%)` guard, which causes overflow on narrow screens.
- Using `transition-all` or animating `width` to "smooth" reflow; animate only `transform` and `opacity`.
- Testing only at a few preset device sizes in DevTools instead of dragging through every width.

## Quick recap

- Start mobile-first; let content choose breakpoints, written in `em`/`rem`.
- `repeat(auto-fit, minmax(min(15rem, 100%), 1fr))` gives a reflowing grid.
- `flex-wrap: wrap` and `gap` for rows; the flex sidebar trick for two columns.
- Container queries let components respond to their own width.
- Check against [WCAG Understanding 1.4.10 Reflow](https://www.w3.org/WAI/WCAG22/Understanding/reflow.html).

## Try it

Open the **Do** tab and turn a fixed card row into a layout that reflows.


Build a card grid, wrapping navigation and a container query that reflow at any width.

Responsive layout patterns

Breakpoint-Free CSS Grid Layouts

## Why this matters

Images are usually the heaviest part of a page. Sending a 2400 px wide photo to a 360 px phone wastes data and slows the page, which hits people on prepaid plans and slow connections hardest. Images without dimensions also make the page jump as they load (layout shift), which is disorienting for everyone and especially for people with cognitive or vision impairments who lose their place. HTML has built-in tools for all of this.

## Step 1: let images shrink

```css
img { max-width: 100%; height: auto; }
```

`max-width: 100%` stops an image overflowing its container; `height: auto` keeps the aspect ratio. Put this in every stylesheet.

## Step 2: always set width and height

```html
<img src="trail-800.jpg" width="1600" height="900" alt="Hikers on a ridge at sunrise">
```

The numbers are the image's intrinsic size (or any pair with the same ratio). Browsers use them to reserve the right space before the file arrives, and the CSS above still makes it responsive. This is the single biggest fix for Cumulative Layout Shift. CSS `aspect-ratio` does the same job for elements without intrinsic dimensions.

## Step 3: srcset and sizes (resolution switching)

When the **same picture** is needed at different sizes, offer several files and let the browser choose:

```html
<img
  src="trail-800.jpg"
  srcset="trail-480.jpg 480w, trail-800.jpg 800w, trail-1600.jpg 1600w"
  sizes="(min-width: 60rem) 50vw, 100vw"
  width="1600" height="900"
  alt="Hikers on a ridge at sunrise">
```

- `srcset` lists files with their real widths (`480w` means 480 pixels wide).
- `sizes` tells the browser how wide the image will be **displayed**: half the viewport on wide screens, the full viewport otherwise. The browser needs this before CSS loads.
- The browser multiplies the display width by the screen's pixel density and picks the smallest file that is big enough. A phone at 360 px and 3x density needs about 1080 px, so it takes `trail-1600.jpg`; a 1x laptop showing it at 600 px takes `trail-800.jpg`.
- `src` is the fallback for very old browsers.

For a fixed-size image (like an avatar) use density descriptors instead: `srcset="avatar.jpg 1x, avatar@2x.jpg 2x"`.

## Step 4: picture for formats and art direction

`<picture>` lets you offer modern formats with a fallback, or a different crop at different sizes:

```html
<picture>
  <source type="image/avif" srcset="team.avif">
  <source type="image/webp" srcset="team.webp">
  <img src="team.jpg" width="1200" height="800" alt="The support team at their desks">
</picture>
```

The browser uses the first `<source>` it supports. The `<img>` inside is required: it is what actually renders, and it carries `alt`, `width`, `height` and `loading`. For **art direction**, add `media` to a source, for example a tight square crop for phones:

```html
<picture>
  <source media="(min-width: 40rem)" srcset="banner-wide.jpg">
  <img src="banner-square.jpg" width="800" height="800" alt="A bowl of ramen">
</picture>
```

## Step 5: lazy-load what is off screen

```html
<img src="gallery-3.jpg" loading="lazy" width="800" height="600" alt="...">
```

`loading="lazy"` delays images below the fold until the user scrolls near them. **Do not** lazy-load the main image at the top of the page (often the Largest Contentful Paint element); it should load immediately, and `fetchpriority="high"` can help it start sooner.

## Alt text still matters

Every responsive technique above is about the file. The `alt` attribute is still what screen reader users get, and it goes on the `<img>`, not on `<source>`. Describe what the image conveys in context; use `alt=""` for decorative images. A chart or diagram needs a text equivalent nearby (a sentence or a data table) when `alt` is not enough.

## Worked example: a recipe page

The page has a hero photo, a step-by-step gallery of six photos further down and a decorative divider. A good result:

- Hero: `srcset` with 3 widths, `sizes="100vw"`, `width`/`height`, no `loading="lazy"`, a descriptive `alt`.
- Gallery: `loading="lazy"`, `width`/`height`, alt text for each step ("Folding the dough in half").
- A `<picture>` for the hero offering AVIF and WebP before the JPEG.
- Divider: `alt=""` or, better, a CSS border.

## Common mistakes

- `srcset` with `w` descriptors but no `sizes`: the browser assumes `100vw` and may download a file far too big.
- Missing `width` and `height`, causing layout shift.
- Lazy-loading the hero image.
- Putting `alt` on `<picture>` or `<source>` (it belongs on `<img>`).
- Using CSS background images for content images, which have no alt text.

## Quick recap

- `img { max-width: 100%; height: auto; }` plus `width`/`height` attributes.
- `srcset` + `sizes` for resolution switching; `<picture>` for formats and art direction.
- `loading="lazy"` below the fold only.
- `alt` on the `<img>`, always.
- Reference: [MDN: Responsive images](https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Responsive_images) and [W3C WAI Images tutorial](https://www.w3.org/WAI/tutorials/images/).

## Try it

Open the **Do** tab and make a gallery page's images responsive. (The preview has no network, so images show as broken; the checks look at your markup and CSS.)


Serve the right image size and format with srcset, sizes, picture and lazy loading.

Responsive images

srcset and sizes attributes - [ images on the web | part one ]

The HTML picture element explained [ Images on the web part 3 ]

Fluid type and spacing with clamp(), layouts that reflow without breakpoints, and images that load the right size.

Responsive Design

Open the page, open DevTools, go to the Lighthouse panel, select only the Accessibility category and run it. Write down the score and every failed audit name.

Install the free axe DevTools browser extension, open its DevTools tab and click Scan all of my page. Export or copy the list of issues with their impact levels.

Open a menu, dialog or form error on the page (submit an empty form if there is one) and scan again. Note any new issues that appear only in that state.

Group duplicate issues that come from the same component or style, and count how many distinct problems you really have.

Rank the distinct problems: first anything that blocks a task (labels, keyboard, names on buttons), then contrast, then structure. Mark any you think are false positives and check them manually.

Pick the top three and write each as a ticket: WCAG criterion, page and element, problem, proposed fix, and how to verify the fix.

Do a five-minute keyboard-only pass of the same page and add one issue the tools did not report.

## Why this matters

You cannot check every heading, label and colour pair by eye on every release. Automated accessibility tools scan a page in seconds and catch the mechanical failures: missing alt text, unlabelled inputs, low contrast, duplicate ids, missing page language. They are the cheapest testing you will ever do. They also have a hard limit: they only catch a portion of WCAG issues (estimates usually range from about a third to a little over half, depending on how you count). A clean score does not mean a page is accessible. This lesson teaches you to run the tools, read their results and decide what to fix first.

## The main free tools

| Tool | Where | Engine | Good at |
|---|---|---|---|
| **Lighthouse** | Chrome DevTools, Lighthouse panel | axe-core (a subset of rules) | A quick score in a report alongside performance and SEO |
| **axe DevTools** (free extension) | Chrome, Edge, Firefox | axe-core | Detailed issues with the element, the WCAG criterion and how to fix it |
| **WAVE** | Browser extension by WebAIM | Its own | Visual overlay of icons on the page: structure, labels, contrast |
| **DevTools Accessibility pane** | Chrome, Firefox, Safari | Browser | Each element's computed role, name and state; the accessibility tree |
| **Contrast checkers** | DevTools colour picker, WebAIM Contrast Checker | Math | Ratio between two colours |

The W3C keeps a [list of evaluation tools](https://www.w3.org/WAI/test-evaluate/tools/list/) if you need more.

## Running Lighthouse

1. Open the page in Chrome, then DevTools (F12 or Cmd+Option+I).
2. Choose the **Lighthouse** panel, tick **Accessibility** (you can untick the others), pick Mobile or Desktop, and click **Analyze page load**.
3. The report gives a score out of 100 and lists failed audits. Each one expands to show the failing elements.

The score is weighted by how many rules failed, not how badly users are affected. A page can score 100 and still be unusable by keyboard. Treat the score as a smoke alarm, not a certificate.

## Running axe DevTools

1. Install the free axe DevTools extension and open DevTools; it adds an **axe DevTools** tab.
2. Click **Scan all of my page**.
3. Each issue shows an **impact** (critical, serious, moderate, minor), the WCAG criterion, the element (click to highlight it), and a "more info" link explaining the fix.
4. Rescan after each fix. Scan again with menus, dialogs and error states **open**: tools only see what is in the DOM at that moment.

Because axe-core is open source, the same rules run in CI. Teams often add `@axe-core/playwright` or `jest-axe` checks to their test suites so new violations fail the build.

## Triage: deciding what to fix first

A first scan of a real site can list hundreds of issues. Do not work top to bottom. Sort them:

1. **Group duplicates.** Fifty "link has no discernible name" errors are often one icon component. Fix the component once.
2. **Rank by user impact.** Things that block a task (unlabelled checkout button, keyboard trap, missing form labels) beat things that annoy (redundant alt text).
3. **Weigh by where it is.** An issue on the login, checkout or sign-up flow matters more than one on an old blog post.
4. **Mark false positives with a note.** Tools sometimes flag contrast on text over images or gradients they cannot measure; check manually and record your decision.
5. **Record each fix as a ticket:** criterion, page, element, problem, proposed fix, and how to verify.

## What tools cannot tell you

Automated checks cannot judge:

- Whether alt text is **accurate** ("image123" passes; so does the wrong description).
- Whether the **focus order** makes sense or focus is visible.
- Whether a custom widget actually works with a keyboard and screen reader.
- Whether headings describe their sections, link text makes sense out of context, or error messages are helpful.
- Captions accuracy, reading level, and whether motion or time limits cause problems.

So every audit pairs tools with manual checks: the keyboard walk-through from Module 1, zoom to 200 and 400 percent, a screen reader pass (next lesson), and a look at the page with CSS turned off or in reader mode to check the order. The W3C's [Easy Checks](https://www.w3.org/WAI/test-evaluate/preliminary/) is a good manual starter list.

## Worked example: triaging a scan

An axe scan of a shop's product page returns: 1 critical "Buttons must have discernible text" on the cart icon (in the header on every page), 12 serious "Elements must meet minimum color contrast" on grey review dates, 3 serious "Form elements must have labels" on the quantity and size fields, and 1 moderate "Heading levels should only increase by one".

Order of work: the quantity and size labels (they block buying), the cart icon name (global, blocks reaching the cart), then contrast (one CSS colour token fixes all twelve), then the heading level. Then a keyboard pass, which finds that the size picker cannot be reached by Tab at all: a bigger bug the tool never flagged.

## Common mistakes

- Chasing a Lighthouse score of 100 as the goal.
- Scanning only the home page.
- Scanning only the default state (menus closed, no errors shown).
- Fixing symptoms page by page instead of in shared components.
- Skipping manual testing because "the tool passed".

## Quick recap

- Lighthouse and axe both use axe-core; WAVE and the DevTools Accessibility pane add other views.
- Tools catch only a portion of issues; always add manual checks.
- Triage by duplicates, user impact and task importance; fix components once.
- Rescan every state, and consider automated checks in CI.

## Try it

Open the **Do** tab and audit a real page with Lighthouse and axe, then triage the results.


Run Lighthouse and axe DevTools, understand their limits, and triage the results.

Automated audits

Getting Started with the axe DevTools Browser Extension

Debugging accessibility with Chrome DevTools

Start the screen reader (NVDA: Ctrl+Alt+N; VoiceOver: Cmd+F5) and spend five minutes in its built-in tutorial or quick-start guide. Practise silencing speech (Ctrl) and stopping the screen reader.

Load the page with your eyes on the keyboard, not the screen. Write down what is announced first, including the page title.

Move through every heading (NVDA: H; VoiceOver: VO+Cmd+H or the rotor with VO+U). Sketch the heading outline you heard and note any skipped levels.

List the landmarks (NVDA: D; VoiceOver: rotor, Landmarks). Note whether main and navigation regions exist and whether multiple navigation regions are named.

Open the list of links (NVDA: NVDA+F7; VoiceOver: rotor, Links). Note every link whose text does not make sense on its own.

Tab through a form. For each field, record exactly what is announced: label, role, required, and any hint. Submit it empty and note whether the errors are announced.

Write up your three most serious findings as: what you heard, WCAG criterion, and proposed fix.

Turn the screen reader off and check that your computer's normal speech settings are back to how you like them.

## Why this matters

A screen reader is the most demanding test of your markup. It exposes every missing label, vague link, skipped heading and silent update. You do not need to become an expert user, but every front-end developer and product designer should be able to do a basic pass: navigate by headings and landmarks, tab through controls, fill in a form and listen to what is announced. It takes about fifteen minutes to learn the basics and finds problems no automated tool can.

Remember that experienced screen reader users are much faster than you, and use settings and habits you will not. Your test checks that the page *can* be used; it is not a substitute for testing with disabled people, which good teams also do.

## Pick a pairing

Screen readers are tested with the browser their users most often pair them with:

| Screen reader | OS | Cost | Test with |
|---|---|---|---|
| **NVDA** | Windows | Free (nvaccess.org) | Firefox or Chrome |
| **JAWS** | Windows | Paid (free 40-minute demo mode) | Chrome or Edge |
| **VoiceOver** | macOS, iOS | Built in | Safari |
| **Narrator** | Windows | Built in | Edge |
| **TalkBack** | Android | Built in | Chrome |

WebAIM's screen reader user survey consistently shows NVDA, JAWS and VoiceOver as the most used. If you have a Mac, start with VoiceOver; on Windows, install NVDA.

## Two modes

Screen readers on the desktop have two ways of moving:

- **Browse (or virtual cursor) mode:** the arrow keys read the page line by line, and single letters jump by element type. This is how people *read*.
- **Focus (or forms) mode:** keys go straight to the focused control so you can type in a field. NVDA switches automatically when you tab into an input; you can toggle with NVDA+Space.

## Essential keys

**NVDA** (the NVDA key is Insert, or Caps Lock if you choose the laptop layout):

- Start/stop: Ctrl+Alt+N to start; NVDA+Q to quit. Ctrl silences speech.
- Down Arrow: next line. NVDA+Down Arrow: read from here.
- H / Shift+H: next / previous heading. 1 to 6: heading at that level.
- D: next landmark. K: next link. F: next form field. B: next button. T: next table.
- Tab: next focusable element.
- NVDA+F7: Elements List (all links, headings, landmarks, form fields).

**VoiceOver on macOS** (VO = Control+Option):

- Start/stop: Cmd+F5 (or hold Cmd and triple-press Touch ID).
- VO+Right/Left Arrow: next / previous item. VO+A: read from here.
- VO+Cmd+H: next heading. VO+U: open the **rotor**, then Left/Right Arrow to pick headings, links, landmarks or form controls.
- Tab: next focusable element. VO+Space: activate.
- Turn on "Press Tab to highlight each item on a webpage" in Safari settings, Advanced, so Tab reaches links.

Keep the official guides open the first time: [NVDA User Guide](https://download.nvaccess.org/documentation/userGuide.html) and Apple's VoiceOver User Guide.

## A repeatable test script

Run the same checks on every page so results are comparable:

1. **Page load.** Is the page `<title>` announced and does it say where you are?
2. **Headings.** Press H (or use the rotor) through every heading. Do they form a sensible outline, with one h1 and no skipped levels? Could you understand the page from the headings alone?
3. **Landmarks.** Press D (or use the rotor). Are there banner, navigation, main and contentinfo regions? Are multiple navs labelled ("Main", "Footer")?
4. **Links.** Open the Elements List or rotor of links. Does each make sense out of context? "Read more" ten times does not.
5. **Images.** Arrow through: are informative images described and decorative ones silent?
6. **Forms.** Tab through a form. Does each field announce its label, whether it is required, and its hint? Submit with errors: are the errors announced, and can you get to them?
7. **Widgets.** Open a menu, accordion or dialog. Is its state announced ("collapsed", "expanded", "dialog")? Does focus move into a dialog and back out when it closes?
8. **Updates.** Add to cart or save something. Is the status ("Added to cart") announced without your focus moving?

## Writing up what you hear

Write down what the screen reader **said**, not what you expected: "Tabbing to the search button announces 'button' with no name". Pair it with the criterion (4.1.2) and the fix (`aria-label="Search"`). Recording the screen with audio, with permission and no personal data on screen, makes bugs much easier to reproduce.

## Worked example: a sign-up form

Testing a sign-up page with NVDA and Firefox: H finds "Create your account" (h1) and then "Already registered?" as an h4, a skipped level. F moves to the first field and NVDA says "edit, blank": the field has only a placeholder and no label. The password hint is never read because it is not linked with `aria-describedby`. Submitting with errors changes the border colour, but nothing is announced. Four findings, all fixable with HTML from Module 1, none caught as clearly by an automated scan.

## Common mistakes

- Testing with the mouse while the screen reader runs. Users navigate with the keyboard (or touch gestures on mobile).
- Testing VoiceOver in Chrome or NVDA in Safari-like pairings users rarely use.
- Assuming one screen reader's behaviour is universal; they differ, so test with at least two over a project.
- Fixing for one screen reader with hacks instead of fixing the underlying HTML.
- Turning speech so slow that you lose patience; it is fine to speed it up as you get used to it.

## Quick recap

- NVDA with Firefox/Chrome on Windows, VoiceOver with Safari on macOS are the starting pairs.
- Learn browse vs focus mode and the heading, landmark, link and form shortcuts.
- Use the same eight-step script on every page and write down exactly what you hear.
- See also: [W3C WAI: Involving Users in Evaluating Web Accessibility](https://www.w3.org/WAI/test-evaluate/involving-users/).

## Try it

Open the **Do** tab and test a page with a screen reader using the script above.


Test a page with NVDA or VoiceOver using a repeatable script and write up what you hear.

Screen reader testing

Screen Reader Basics: NVDA -- A11ycasts #09

Getting started with Mac’s VoiceOver screen reader

## Why this matters

This lesson puts the whole course together. Real accessibility work usually starts with an existing page full of problems, a deadline, and no time to rebuild it. The skill is to find the issues quickly, fix the ones that matter most with the smallest correct change, and verify each fix. Developers do this in bug-fix tickets; designers do it when reviewing a build against the design; both do it in audits.

## A five-minute audit routine

Use the same order every time. It moves from the cheapest checks to the most effort.

1. **Automated scan.** axe or Lighthouse (Lesson 1). Note the issues.
2. **Page basics.** Is there a `lang` on `<html>` (3.1.1)? A specific `<title>` (2.4.2)? One `<h1>` and no skipped heading levels (1.3.1)?
3. **Keyboard.** Tab through everything. Is focus visible (2.4.7)? Can you reach and operate every control (2.1.1)? Is there a skip link (2.4.1)?
4. **Names.** Every image has a fitting `alt` (1.1.1); every input has a label (3.3.2, 4.1.2); every button and link has text that makes sense (2.4.4).
5. **Colour.** Text contrast at least 4.5:1, large text 3:1 (1.4.3); nothing relies on colour alone (1.4.1).
6. **Zoom and reflow.** 200 percent text zoom and a 320 px wide window (1.4.4, 1.4.10).
7. **Motion.** Animations respect `prefers-reduced-motion`, nothing flashes more than three times a second (2.3.1), and anything that moves on its own for more than five seconds can be paused (2.2.2).
8. **Screen reader spot check** on the key task (Lesson 2).

## Fixing contrast properly

Contrast ratio compares the **relative luminance** of two colours, from 1:1 (same colour) to 21:1 (black on white). You do not need to calculate it by hand; DevTools shows the ratio in the colour picker when you inspect text, and suggests a passing colour. For reference, the formula from WCAG is:

```js
// sRGB channel (0-255) to linear light
const lin = c => { c /= 255; return c <= 0.03928 ? c / 12.92 : ((c + 0.055) / 1.055) ** 2.4; };
const lum = ([r, g, b]) => 0.2126 * lin(r) + 0.7152 * lin(g) + 0.0722 * lin(b);
const ratio = (a, b) => { const [hi, lo] = [lum(a), lum(b)].sort((x, y) => y - x); return (hi + 0.05) / (lo + 0.05); };

ratio([153, 153, 153], [255, 255, 255]); // #999 on white: about 2.85, fails
ratio([89, 89, 89], [255, 255, 255]);    // #595959 on white: about 7.0, passes AA and AAA
```

Fix contrast in the **design tokens** (one CSS custom property), not element by element, so every use improves at once. Remember to check hover, focus, disabled and placeholder states, and text on images.

## Reduced motion

Some people get dizzy or nauseous from parallax, zooming and large movement. Respect their system setting:

```css
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}
```

A blanket rule like this is a safe starting point; a better design swaps movement for a gentle fade rather than removing feedback entirely.

## Worked example: a broken landing page

A landing page has: no `lang`; a hero image with no `alt`; light grey `#aaa` text on white in a notice; an email input with only a placeholder; a "Get started" `<div>` with a click handler; an `<h1>` followed directly by `<h4>`.

The smallest correct fixes:

| Issue | WCAG | Fix |
|---|---|---|
| No page language | 3.1.1 | `<html lang="en">` |
| Image with no alt | 1.1.1 | `alt="..."` describing it, or `alt=""` if decorative |
| `#aaa` on white (2.3:1) | 1.4.3 | A darker token, such as `#595959` (7:1) |
| Placeholder-only input | 3.3.2, 4.1.2 | `<label for="email">Email address</label>` |
| Div button | 2.1.1, 4.1.2 | `<button type="button">Get started</button>` |
| h1 then h4 | 1.3.1 | Change to `<h2>`, and resize with CSS if needed |

After fixing, verify each one the same way you found it: rescan, tab through, check the ratio in DevTools, and listen with a screen reader.

## Writing the summary

Close an audit with a short summary for the team: what you tested (pages, tools, browsers, screen readers), what you fixed, what remains with severity, and a recommendation (for example, "add axe checks to CI so these do not return"). For formal audits, the W3C's [WCAG-EM methodology](https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/) and its free report tool describe how to sample pages and report conformance.

## Common mistakes

- Rewriting a whole component when one attribute would do.
- Fixing the visible symptom (a darker colour on one element) instead of the token.
- Adding ARIA to a `<div>` instead of swapping in the native element.
- Not re-testing after a fix.
- Changing a heading level by restyling instead of changing the element.

## Quick recap

- Audit in a fixed order: scan, basics, keyboard, names, colour, zoom, motion, screen reader.
- Prefer the smallest native-HTML fix; fix shared tokens and components.
- Contrast: 4.5:1 text, 3:1 large text and UI; check with DevTools.
- Respect `prefers-reduced-motion`.
- Verify every fix the way you found it.

## Try it

Open the **Do** tab and fix five accessibility issues in a broken landing page.


Audit a broken landing page and fix five WCAG failures with the smallest correct changes.

Fix an inaccessible page

Use WAVE to start a manual accessibility audit

Run automated audits, test with a screen reader, and fix a broken page from scan to verified fix.

Accessible & Responsive Interfaces

About this course

Course content

Accessibility Essentials

Responsive Design

Testing and Auditing

Where this course leads

Next course on the path

Careers that use it