βΏ
EPISODE 01
WCAG Β· POUR Β· screen readers Β· why it matters
Accessibility Concepts
Accessibility is not a nice-to-have. Learn the WCAG framework (POUR), how screen readers consume your page, and the legal/business case.
a11yWCAGPOURscreen reader
Duration
β± About 1.5 hours
Level
π Intermediate
Prerequisite
π― HTML + CSS basics
OUTCOME
Audit a page with a screen reader and a checklist
What you'll learn
- 1Explain WCAG and the four POUR principles
- 2Run a basic screen-reader test (VoiceOver, NVDA)
- 3Recognize common a11y wins (alt text, headings, focus)
- 4Use Lighthouse and axe-core for automated audits
1. Why Accessibility?
- ~15% of the world lives with a disability β your users
- Better a11y = better SEO and better usability for everyone
- Legally required in many countries (ADA, EAA)
- Costs almost nothing if built in from day one
2. POUR β The WCAG Pillars
| Principle | Means |
|---|---|
| Perceivable | Content can be perceived by sight, sound, or touch (alt text, captions, contrast) |
| Operable | All actions work with keyboard alone (no mouse-only menus) |
| Understandable | Predictable navigation, clear errors, plain language |
| Robust | Works with assistive technologies and future browsers |
3. WCAG Levels
- A β minimum
- AA β most regulations target this
- AAA β gold standard, rarely fully achievable site-wide
4. Quick Audit Tools
- Lighthouse (Chrome DevTools) β automated checks
- axe DevTools β deeper accessibility issues
- VoiceOver (macOS) Cmd+F5 / NVDA (Windows) β real screen-reader testing
- Tab through your site with the keyboard β focus order should make sense
π‘
Automated tools catch ~30% of issues. Always do a manual keyboard + screen-reader test before shipping.
Example code / lecture materials
All lecture materials and example code are openly available on GitHub.
View on GitHub β