In this article · 7 sections
Roughly one in six people worldwide lives with a significant disability, according to the World Health Organization. Many more experience temporary or situational limits: a broken arm, bright sunlight on a screen, a noisy train, a slow connection. Accessibility is the practice of making digital products usable by as many people as possible in as many situations as possible.
It is also good business and, in many places, a legal expectation. This guide explains the fundamentals in plain language and gives you practical steps you can apply to apps and websites right away.
Accessibility benefits everyone
Features built for accessibility tend to improve the experience for all users.
- Captions help people in loud places or who cannot play audio, as well as those who are deaf.
- High contrast and clear type help everyone in direct sunlight.
- Keyboard support helps power users and people with motor impairments.
- Clear, simple language helps non-native speakers and people in a hurry.
- Large touch targets help anyone using a phone one-handed.
It is also a matter of reach and fairness. A product that excludes people is a product with a smaller audience.
The standard to know: WCAG
The Web Content Accessibility Guidelines (WCAG), published by the W3C, are the most widely referenced accessibility standard, and are the basis for many laws and procurement requirements. The current version is WCAG 2.2. Although written for the web, its principles are also used to guide mobile apps.
WCAG is organised around four principles, often remembered as POUR:
- Perceivable: information must be presentable in ways users can perceive (text alternatives, captions, sufficient contrast).
- Operable: the interface must be usable with different input methods (keyboard, touch, voice, switch devices) and give enough time.
- Understandable: content and behaviour must be clear and predictable.
- Robust: content must work with a wide variety of technologies, including assistive tools.
Conformance has three levels: A, AA and AAA. Most organisations target AA as a sensible goal.
Practical fundamentals
1. Colour and contrast
- Normal text should have a contrast ratio of at least 4.5:1 against its background, and large text at least 3:1 (WCAG AA).
- Interface components and meaningful graphics, such as input borders and icons, need at least 3:1.
- Never rely on colour alone to show meaning. An error shown only in red is invisible to many users. Add an icon, a label or text.
- Test your palette with a contrast checker, and check dark mode separately.
2. Text and readability
- Use readable font sizes and respect users’ system text-size settings. Layouts should not break when text is enlarged.
- Keep line length and spacing comfortable.
- Write in plain language. Short sentences and clear headings help everyone.
- Use real text instead of text embedded in images.
3. Alternative text for images
Describe images that carry information, such as charts, product photos or icons that act as buttons. Mark purely decorative images so assistive technology skips them. Good alt text conveys the purpose, not just the appearance.
4. Headings, labels and structure
- Use proper heading levels in order so people can navigate by headings.
- Give every form field a visible, associated label. Placeholder text alone disappears and is not a label.
- Write descriptive link and button text. “Read the pricing guide” is better than “Click here”.
- Provide clear error messages that say what went wrong and how to fix it.
5. Keyboard and focus support
Many people navigate without a mouse or touchscreen. On the web:
- Everything interactive must be reachable and usable with the keyboard.
- Keep a logical focus order and a clearly visible focus indicator.
- Avoid keyboard traps where focus gets stuck.
- Provide a “skip to content” link so users can bypass repeated navigation.
On mobile, similar ideas apply to external keyboards, switch control and voice control.
6. Touch targets and gestures
- Make tap targets large enough. WCAG 2.2 sets a minimum target size, and platform guidelines recommend larger: around 44 × 44 points on iOS and 48 × 48 dp on Android.
- Leave space between targets to prevent accidental taps.
- Offer simple alternatives to complex gestures such as multi-finger or path-based gestures.
- Avoid actions that require precise timing.
7. Screen reader support
Screen readers such as VoiceOver (iOS and macOS), TalkBack (Android) and NVDA or JAWS (Windows) read the interface aloud.
- Provide accessible names (labels) for buttons, icons and controls.
- Expose the correct roles and states, such as selected, expanded and disabled. On the web, prefer native HTML elements, which come with this built in, and use ARIA only when needed.
- Announce dynamic changes, such as loading complete or a form error, in a way assistive tools can detect.
- Ensure reading order matches visual order.
8. Motion, media and time
- Respect the reduced motion setting. Avoid large, constant or parallax animations for users who ask to limit motion.
- Don’t flash content more than three times per second, as it can trigger seizures.
- Provide captions for video and transcripts for audio.
- Let users pause, stop or extend time limits and moving content.
- Don’t autoplay audio.
How to test accessibility
Automated tools catch only a portion of issues, so combine methods.
- Automated scans. Tools such as Lighthouse, axe and WAVE find common problems like missing labels and low contrast. They are a quick first pass.
- Keyboard testing. Put your mouse away and complete key tasks using only the keyboard.
- Screen reader testing. Try main journeys with VoiceOver, TalkBack or NVDA. It feels awkward at first, but it reveals real barriers.
- System settings checks. Test with large text, high contrast, reduced motion, dark mode and zoom up to 200 percent.
- Manual review. Check headings, labels, error handling and reading order.
- Test with real people. Feedback from users with disabilities is the most valuable source of insight.
Remember that passing automated checks does not prove an experience is accessible. Full validation involves manual testing with assistive technologies and, ideally, expert review.
Build accessibility into your process
Retrofitting is expensive. Make accessibility part of normal work.
- In design: use accessible colour palettes and component states from the start. A good design system bakes these in once for every screen.
- In development: use native components and semantic markup, and add accessibility checks to your pull requests and automated tests.
- In content: write clear copy, alt text and captions.
- In planning: include accessibility acceptance criteria in your user stories.
- In ownership: name someone responsible, and publish a way for users to report accessibility problems.
If you are building your first release, add this to your MVP plan, because the basics cost very little when done from day one.
Quick accessibility checklist
- Text contrast at least 4.5:1 (3:1 for large text and UI components)
- Information not conveyed by colour alone
- Alt text for meaningful images; decorative images hidden from assistive tech
- Logical heading structure and descriptive links
- Visible labels on all form fields; clear error messages
- Full keyboard operation with visible focus
- Touch targets large enough with adequate spacing
- Screen reader names, roles and states provided
- Reduced motion respected; no flashing content
- Captions and transcripts for media
- Tested with automated tools, keyboard, a screen reader and real users
Final thoughts
Accessibility is not a feature added at the end. It is a quality of good design and engineering, built in step by step. Start with contrast, labels, keyboard support and touch targets, test regularly, and keep improving. If you want a team that designs with these principles from the start, see our UI/UX design service or get in touch.
