WebsitesModule 4: Quality and inclusionLesson 11 of 15
Course progress67%
16 min lesson · Updated August 2026
What makes a website accessible?
An accessible website lets disabled people perceive, understand, navigate and operate its content and functions using different senses, devices and assistive technologies; it is built through requirements, design, code, content and testing.
What you will learn
By the end, you will understand:
Understand accessibility as a shared product responsibility
Recognize core keyboard, structure, contrast, form and media needs
Use WCAG and human testing without claiming automatic perfection
Visual explainer
See the idea clearly.
The same website task is completed through sight, screen reader, keyboard, voice, magnification and touch, supported by shared semantic content and flexible controls.
People use websites in different ways
Need
Examples
Vision
Screen readers, magnification, high contrast, meaningful alternatives.
Hearing
Captions, transcripts and visual alerts.
Mobility
Keyboard, switch, voice input and forgiving targets.
Cognition/learning
Clear language, predictable structure and error recovery.
Speech
Alternatives to voice-only contact/authentication.
Temporary/situational
Injury, glare, noise, slow connection or divided attention.
WCAG organizes testable requirements
WCAG principles are perceivable, operable, understandable and robust. Conformance is evaluated against defined success criteria and a scope/version/level—not a vague accessibility score.
Laws and procurement requirements vary. This lesson explains practice, not jurisdiction-specific legal advice.
High-value foundations
Semantic headings/landmarks
Keyboard operation/no trap
Visible unobscured focus
Text alternatives
Captions/transcripts
Labels/instructions
Specific errors/recovery
Sufficient contrast
Zoom/reflow
Touch target size
No color-only meaning
Motion controls
Accessible names/status
Consistent help/navigation
Alternative text depends on purpose
Describe the information or function an image contributes, not every pixel. Decorative images should be ignored; complex diagrams need an equivalent explanation; linked images need a useful action name.
Do not start every alternative with “image of” or use AI descriptions without human contextual review.
Forms need more than placeholders
01
Visible label
02
Instructions/format
03
Programmatic association
04
Keyboard/touch input
05
Validation after appropriate point
06
Specific error identification
07
Preserved values
08
Correction path
09
Success confirmation
Testing combines methods
Automated tools catch some code patterns. Manual keyboard, zoom, screen-reader and content review finds issues automation cannot. Disabled-user involvement reveals real task barriers.
Accessibility overlays cannot automatically guarantee conformance or repair every source problem.
Real-world example
Example: a color-perfect form still fails
Example
A form passes automated contrast checks, but errors appear only as red borders and focus jumps nowhere. The fix adds text errors linked to fields, a summary, preserved input and programmatic status while retaining visual cues.
Try this
Perform three accessibility checks
Complete one task with keyboard only, zoom to 200–400% as appropriate, and inspect images/forms with a screen reader or accessibility tree. Record barriers and exact steps.
Common questions
Questions beginners ask.
What is web accessibility?
Designing and building web content so disabled people can perceive, understand, navigate and operate it.
What is WCAG?
The Web Content Accessibility Guidelines, a W3C standard with principles, guidelines and testable success criteria.
Does accessibility only help blind people?
No. It addresses visual, hearing, mobility, speech, cognitive and other needs.
Can an automated tool prove accessibility?
No. It finds a subset of issues and requires manual and human evaluation.
Do images always need alt text?
Meaningful images need an equivalent; decorative images should be ignored by assistive technology.
Why are placeholders not labels?
They disappear/change, may be low contrast and do not reliably identify a field.
What is visible focus?
A clear indicator showing which interactive element currently receives keyboard input.
Does accessibility make design boring?
No. It creates constraints for inclusive clarity, not one visual style.
