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
Have lived experience or expertise that could strengthen this page? We especially welcome perspectives on models not well represented here, including those from the Global South and Indigenous communities.
Suggest an edit or addition →
This page centers disabled people's expertise and is informed by disabled-led organizing globally. For questions or to suggest additions, see How to Contribute.
Last updated: January 2026