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.