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

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.