Designing for Accessibility

Design for Everyone

Accessibility (a11y) means designing products that people with disabilities can use: people who are blind or have low vision, who are deaf or hard of hearing, who have motor impairments, or who have cognitive or learning differences.

The World Health Organization estimates that about 1.3 billion people, around 1 in 6 people worldwide, live with a significant disability. In Nigeria, estimates run to tens of millions of people. Accessibility also helps everyone: captions help in a noisy danfo, large buttons help when you are holding a baby, and high contrast helps in bright Lagos sunshine. Designers call this the curb-cut effect.

---

WCAG: The Global Standard

The Web Content Accessibility Guidelines (WCAG) are published by the W3C. WCAG 2.2 is the current version. Most laws and company policies target level AA.

WCAG is organised around four principles, remembered as POUR:

Perceivable

Users must be able to perceive the content.

• Text alternatives (alt text) for meaningful images
• Captions for video and transcripts for audio
• Sufficient colour contrast: 4.5:1 for body text, 3:1 for large text and UI components
• Do not rely on colour alone

Operable

Users must be able to operate the interface.

• Everything works with a keyboard or switch device
• A visible focus indicator
• Touch targets at least 24 × 24px under WCAG 2.2, and 44–48px recommended by Apple and Google
• No time limits that cannot be extended, like an OTP that expires in 30 seconds with no resend
• No content that flashes more than three times per second

Understandable

• Plain, simple language
• Labels on every form field (placeholders are not labels, because they disappear when you type)
• Clear error messages that explain how to fix the problem
• Predictable navigation

Robust

• Works with assistive technologies such as screen readers
• Built with semantic elements (real buttons, headings and lists), which is mostly an engineering concern that designers must specify

---

Screen Readers

Screen readers (VoiceOver on iOS, TalkBack on Android, NVDA and JAWS on Windows) read the interface aloud. Designers can help by specifying:

• Reading order: the order elements are announced
• Accessible names for icon-only buttons. A 🔍 icon should be announced as "Search", not "button"
• Headings to navigate by. Screen reader users jump from heading to heading
• State announcements: "Transfer successful", "3 new messages"

Try it yourself: turn on TalkBack or VoiceOver and try to send money in your own banking app. It is an eye-opening five minutes.

---

Inclusive Design Beyond Compliance

WCAG is the floor, not the ceiling. Inclusive design means considering the full range of human diversity from the start.

• Permanent, temporary and situational disabilities: one arm, a broken arm, holding a phone on a bus
• Literacy and language: icons plus words, simple vocabulary, local languages, and voice options
• Low-end devices and data: lightweight pages, offline support, SMS or USSD fallbacks. In Nigeria, USSD banking is itself an inclusion tool for people without smartphones.
• Older users: larger text support, fewer steps and patient timeouts

---

Building Accessibility Into Your Process

1. Research: include people with disabilities in your research and testing.
2. Design: check contrast, touch targets and focus order as you go, using plugins like Stark or Contrast.
3. Annotate: add accessibility notes to your handoff.
4. Test: use screen readers, keyboard-only navigation and automated tools like axe or Lighthouse, but remember automated tools catch only around 30 to 40 percent of issues.
5. Fix and repeat.

---

Try It in the Lab

The accessibility audit tool shows a sign-up screen with several problems. Work through the WCAG checklist and mark each item pass or fail. The tool measures real contrast ratios and touch target sizes on the screen, then lets you toggle fixes and re-audit. Your goal is a clean AA audit.