Web accessibility fundamentals
Web accessibility means enabling anyone, whatever their abilities and assistive technologies, to perceive, understand, navigate and interact with a site. This guide presents the four WCAG POUR principles, then key recommendations by topic.
The essentials
- Four principles: Perceivable, Operable, Understandable, Robust (POUR).
- Semantic HTML first, ARIA only as a complement.
- Automatic overlays do not make a site compliant.
- Real-world tests (keyboard, screen reader, users) always complement automated audits.
The four POUR pillars of WCAG
Each WCAG criterion belongs to one of these principles.
- Perceivable
- Transcripts, text alternatives, sufficient contrast, clear visual organisation.
- Operable
- Keyboard navigation, logical tab order, skip links, mobile compatibility.
- Understandable
- Declared language, consistent feedback, simple instructions, cognitive accessibility.
- Robust
- Compatibility with assistive technologies, correct ARIA, valid code.
Keyboard navigation and focus
Everything must work without a mouse: focus order matching visual order, always-visible focus (at least 3:1 contrast), a skip link at the top, no keyboard traps. Avoid positive tabindex values. Use tabindex="-1" only for elements focused by script, not to “remove” interactive elements, which would become inaccessible.
Test with: Tab, Shift+Tab, Enter, Space, arrow keys. Detailed keyboard navigation guide.
Form accessibility
One <label for> per field, instructions before the field, explicit errors linked to the field, <fieldset> and <legend> for groups, an alternative to CAPTCHAs, autocomplete on personal data. Detailed forms guide.
Cognitive accessibility and neurodiversity
Plain language, explained abbreviations, numbered steps, no uncontrollable autoplay animation, respect for prefers-reduced-motion, generous spacing, immediate feedback after each action. Detailed guide.
ARIA: best practices
Golden rule: “no ARIA is better than bad ARIA”. Use the native HTML element first; ARIA complements, it doesn’t replace. Detailed ARIA guide.
Media and dynamic content
Transcripts, synchronised captions (WebVTT), audio description, no autoplaying sound, accessible controls. Detailed guide.
Mobile accessibility
Large, well-spaced touch targets, zoom allowed, no dependence on hover, testing with VoiceOver and TalkBack. Detailed guide.
Accessibility overlays: a warning
Automatic widgets and toolbars do not deliver WCAG or RGAA compliance: they do not fix the source code and can interfere with assistive technologies. In January 2025 the US FTC penalised an overlay vendor for misleading claims about automatic compliance. Fix the code, have experts audit it and test with users.
References: Overlay Fact Sheet and why avoid overlays.
Testing with real users
- Include people with visual, motor, hearing and cognitive disabilities.
- Observe real navigation, then collect feedback with adapted questionnaires.
- Test with keyboard only, a screen reader (NVDA, JAWS, VoiceOver) and touch.
- Combine automated audits (axe, WAVE…) with manual checks.
Intersectionality, localisation and languages
Declare the language (lang) and its changes, write text that machine-translates well, localise dates, times and currencies, and test across regions and languages. Reference: W3C Internationalization.
Frequently asked questions
What is web accessibility?
It is a site’s ability to be used by everyone, including people with temporary, permanent or situational disabilities, with or without assistive technology.
What does POUR mean in accessibility?
POUR names the four WCAG principles: Perceivable, Operable, Understandable and Robust.
Why do people write a11y?
It is a numeronym: “a”, eleven letters, “y” for “accessibility”.