UX7: Accessible and inclusive design
Why accessibility, and what WCAG asks
🎯You'll be able to
Explain who accessibility helps, describe WCAG's four principles and levels, and say what automated checks can and can't find.
🏠The everyday picture
A ramp at a station entrance helps wheelchair users, and also parents with prams, travellers with suitcases and delivery workers with trolleys. Accessible design works the same way.
📘What it really is
-
Who it helps: people who are blind or have low vision, are deaf or hard of hearing, have limited movement, or have cognitive or learning disabilities; and everyone in a situational limit: bright sunlight, one hand holding a child, a cracked screen, a noisy bus.
-
WCAG (Web Content Accessibility Guidelines) 2.2, published by the W3C in 2023, is the standard most organisations follow. Its four principles are POUR:
- Perceivable: people can see or hear the content (contrast, text alternatives, captions).
- Operable: people can use it (keyboard, enough time, target size, no traps).
- Understandable: content and behaviour are clear (plain words, predictable, helpful errors).
-
Robust: it works with assistive technology (proper HTML, names, roles and states).
-
Levels: A (minimum), AA (the usual target in laws and policies), AAA (enhanced). Indian government websites follow GIGW, which builds on WCAG.
-
Automated tools such as axe find many problems quickly (missing names, contrast, wrong roles), but not all: they can't tell if a label makes sense, if focus order is logical, or if a placeholder will be forgotten. Manual checks and testing with disabled people are needed too.
📝A worked example
Input: the starter journey and axe (npm run test:prototype, test 1).
Expected output on the starter's search page: color-contrast: 9 and label: 1. axe flags the unlabelled checkbox, but not the search
box whose only name is a placeholder, and it can't notice that the slot "buttons" are divs that a keyboard can't reach; tests 2 and 3
check those. After the redesign, axe reports no serious or critical problems on any page.
🌍Where it's used
- Banks and payment apps, checked against WCAG AA before release.
- Government portals, following GIGW.
- Large employers, whose internal tools must work for disabled staff.
📝Case scenario
A food delivery app passed its automated accessibility checks. A blind tester found she couldn't place an order: the "Add" buttons were images with no names, and the automated tool had missed them because they were inside a custom component. A manual screen reader check was added to every release.
🖱️Try it
Run an automated checker (for example axe in a browser extension, or the kit's test) on any website. Then use the same page with only your keyboard for two minutes. Success: you find at least one problem the tool didn't report.
⚠️Common mistakes
- Accessibility at the end. Sign: a fix list just before launch. Fix: check from wireframes onwards.
- Trusting automated tools alone. Sign: "axe passed, so it's accessible." Fix: keyboard and screen reader checks too.
- Designing for an imagined disabled user. Sign: no disabled participants in research. Fix: recruit them (UX2).
🛠️For your project
Project 2's test 1 runs axe on every page; tests 2, 3 and 7 check what axe can't.
✅Quick check
What are WCAG's four principles?
Show the answer
Perceivable, operable, understandable and robust (POUR).
Name something automated checkers can't find.
Show the answer
Whether a label makes sense, whether focus order is logical, or whether a placeholder will be forgotten.