Web accessibility is about making websites and web apps usable by as many people as possible, including:
- Screen reader users
- Keyboard-only users
- People with low vision or color blindness
- People with cognitive or learning disabilities
- People with chronic pain, fatigue, or limited bandwidth and processing capacity
- People using alternative input devices or older hardware
It’s more than “checking a box” for compliance. It’s about whether disabled people can actually participate.
Many guidelines can be summed up as:
- Perceivable – Information and UI must be available to different senses and modalities.
- Operable – People can navigate and use controls with keyboard, switch devices, or other methods.
- Understandable – Content and interfaces are clear, consistent, and predictable.
- Robust – Works across different browsers, assistive technologies, and devices.
(These principles align with well-known accessibility standards, but this page focuses on plain language and lived impact.)
Examples:
- Images with no alt text or useless alt text (“image123.jpg”)
- Buttons and links that are visually styled but not announced properly to screen readers
- Forms that are impossible to complete with keyboard only
- Low color contrast that makes text unreadable for many people
- Text walls with no headings or structure
- Pop-ups and modals that trap focus or cannot be dismissed
- Motion/animation that can trigger migraine, vertigo, or sensory overwhelm
- CAPTCHA that assumes vision, hearing, or fine motor control
If you build or manage websites, some baseline practices include:
- Meaningful alt text for important images
- Headings in order (H1, H2, H3) to structure content
- Labelled form fields with clear error messages
- Keyboard navigation that works for all interactive elements
- Sufficient color contrast and not relying on color alone to convey information
- Avoiding autoplaying audio/video and providing controls if media is present
- Providing text alternatives for charts, infographics, and complex visuals
Some starting points:
- Use browser dev tools and accessibility inspectors
- Run automated checkers as a first pass, but don’t stop there
- Test with keyboard only (no mouse or touchpad)
- If possible, test with real users who use screen readers and other assistive tech
Community contributions here can include:
- Lists of tools for different roles (designers, devs, content writers)
- Checklists tailored to small teams, nonprofits, or mutual aid projects
- Example “before and after” accessibility fixes
¶ Laws and Standards
Different countries reference different laws and standards (for example, WCAG in many regions). Instead of duplicating legal text, this wiki can:
- Link to official standards and government guidance
- Explain, in everyday language, what those rules mean in practice
- Highlight gaps where laws exist on paper but not in reality
If you add region-specific legal info, please clearly mark:
- The country/region
- The date or “as of YEAR”
- Links to official sources