Accessibility is not a compliance checkbox at the end of a project. It is whether a person using a keyboard, a screen reader or 200% zoom can complete the same task as everyone else.

Learning objectives

• Explain who accessibility affects and why it matters.
• Apply the four POUR principles.
• Understand WCAG 2.1 levels and the AA target.
• Audit a page with keyboard, Lighthouse and a screen reader.

1. Who it is for

Disabilities are permanent, temporary or situational:

• Permanent: blindness, low vision, deafness, motor impairment, cognitive disability.
• Temporary: a broken wrist, an eye infection, a migraine.
• Situational: bright sunlight, a noisy train, holding a baby with one arm, a slow connection.

Everyone benefits from captions, keyboard support and readable contrast. Accessibility is good engineering for the same reason responsive design is.

2. POUR

Perceivable — information must be available to the senses. Text alternatives for images, captions for video, sufficient contrast, content that works at 200% zoom.

Operable — every control works with a keyboard, focus is visible, there are no keyboard traps, and nothing flashes more than three times per second.

Understandable — labels are clear, errors explain how to fix the problem, navigation is consistent.

Robust — valid HTML that assistive technology can parse, with correct names, roles and states.

3. WCAG 2.1

The Web Content Accessibility Guidelines define success criteria at three levels:

• A — the minimum. Missing alt text, keyboard traps, no captions.
• AA — the legal and practical target in most jurisdictions. Contrast 4.5:1 for text, 3:1 for large text and UI components, captions, focus visible, resize text to 200%.
• AAA — enhanced. Contrast 7:1, sign language, extended audio description. Not required for whole sites.

Aim for AA. It covers the vast majority of real barriers.

4. How people actually use the web

Keyboard only — Tab moves forward, Shift+Tab back, Enter activates links and buttons, Space toggles checkboxes and buttons, arrow keys move within groups, Escape closes dialogs.

Screen reader — announces the accessible name, role and state of the focused element, and lets the user jump by headings, landmarks, links and form fields. An unlabelled <div onclick> is announced as nothing.

Zoom and reflow — 200% zoom must not clip content or require horizontal scrolling at a 320 px viewport.

Voice control — the visible label must match the accessible name, or "click Send" does nothing.

5. A practical audit

1. Keyboard pass — unplug the mouse. Can you reach and use everything? Is focus always visible? Does focus order follow the visual order?
2. Zoom — set the browser to 200%. Is anything cut off?
3. Lighthouse — run the accessibility audit. It catches missing alt text, low contrast, missing labels and duplicate ids.
4. axe DevTools — a deeper automated scan.
5. Screen reader — NVDA on Windows or VoiceOver on macOS. Navigate by headings and try one form.
6. Reduced motion — enable the OS setting and confirm animations respect prefers-reduced-motion.

Automated tools catch roughly a third of issues. Keyboard and screen-reader testing catch the rest.

6. The most common failures

• Images without alt (or with alt="image").
• Icon-only buttons with no accessible name.
• Form inputs without a <label>.
• Low-contrast grey text on white.
• outline: none with no replacement focus style.
• Clickable <div>s that cannot be focused or activated by keyboard.
• Heading levels chosen for size, not structure.
• Modals that do not move or trap focus.

Common mistakes

• Treating an automated score of 100 as "accessible".
• Adding ARIA to broken HTML — ARIA cannot fix missing keyboard behaviour.
• Testing only the happy path with a mouse.
• Hiding content with display: none and expecting screen readers to read it (they will not; that is usually correct, but be deliberate).

Practice

Audit a real page in the assignment and fix what you find. Write down the barrier from the user's point of view, not just the rule number.