There's a common misconception that designing for accessibility is about accommodating a small edge-case population — people using screen readers, keyboard-only navigation, or assistive technologies. This framing leads teams to treat accessibility as a compliance exercise done at the end of a project, checking boxes against WCAG guidelines rather than thinking about the humans behind them.

The reality is very different. The World Health Organization estimates that 1.3 billion people — roughly 16% of the world's population — live with some form of disability. In India, the 2011 Census counted 26.8 million people with disabilities; the actual figure in 2026, including people with temporary, situational, and age-related impairments, is substantially higher. Beyond permanent disability, there are the millions of users experiencing situational impairments that your accessibility decisions affect every day: someone using their phone in bright sunlight (low contrast), a new parent with one arm occupied (one-handed mobile use), someone on a noisy train using captions. Designing for accessibility is designing for the full range of human experience.

The Business Case Is Clear

Leaving aside the moral argument — which should be sufficient — the commercial case for accessibility is strong:

  • Market size: The disposable income controlled by people with disabilities in the US alone is estimated at $490 billion annually. Globally, the "disability market" including family and friends exceeds $13 trillion in annual spending.
  • SEO: Accessible HTML — proper heading hierarchy, alt text, labelled form fields, semantic structure — is the same signal that search engines use to understand your content. Accessibility improvements consistently improve search rankings.
  • Legal exposure: Web accessibility lawsuits under the Americans with Disabilities Act (ADA) in the US exceeded 4,000 cases in 2023. India's Rights of Persons with Disabilities Act, 2016 includes provisions for accessible digital products. The trend is towards stricter enforcement in every major market.
  • Reduced support burden: Accessible products are clearer, simpler, and less ambiguous — which means fewer support tickets from all users, not just those with disabilities.

"Accessibility is the discipline that forces you to communicate one clear thing at a time. That constraint makes you a better designer."

The WCAG Framework

The Web Content Accessibility Guidelines (WCAG), published by the W3C, are the internationally accepted standard for digital accessibility. WCAG 2.2 (the current version) organises requirements under four principles, remembered by the acronym POUR:

  • Perceivable: Information and UI components must be presentable in ways users can perceive. Key requirements: text alternatives for non-text content, captions for video, sufficient colour contrast, text can be resized to 200% without loss of functionality.
  • Operable: All functionality must be accessible via keyboard (not only mouse/touch). No time limits that can't be extended. No content that flashes more than 3 times per second (seizure risk).
  • Understandable: Text is readable and understandable. Pages behave predictably. Error messages explain what went wrong and how to fix it.
  • Robust: Content is interpreted reliably by assistive technologies. Proper HTML semantics, ARIA labels where needed, and forward compatibility.

WCAG has three conformance levels: A (minimum), AA (the standard most organisations target), and AAA (enhanced). For most commercial products, WCAG 2.2 AA is the target.

Practical Accessibility: What It Looks Like in Design and Code

Colour Contrast

WCAG 2.2 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt+ or 14pt bold). This is one of the most commonly failed criteria — and one of the most impactful, because it affects readability for all users in suboptimal lighting conditions, not just those with low vision.

Tools: the browser DevTools colour picker shows live contrast ratios; Figma plugins like Colour Contrast Checker integrate into the design process; WebAIM's Contrast Checker is the go-to for quick verification.

Keyboard Navigation

Every interactive element — buttons, links, form fields, modals, dropdowns — must be reachable and operable with the Tab key alone. Focus states must be visible (not hidden with outline: none without a replacement). The focus order must follow a logical reading sequence.

/* Never do this without providing a visible alternative */
:focus { outline: none; }

/* Do this instead */
:focus-visible {
  outline: 3px solid #FF4D00;
  outline-offset: 3px;
  border-radius: 4px;
}

Semantic HTML

Screen readers and other assistive technologies rely on the semantic meaning of HTML elements to describe content to users. Using the right element for the right purpose — <button> for actions, <a> for navigation, <h1>-<h6> for headings in logical order, <label> for form fields — costs nothing and gives you accessibility almost for free.

<!-- Inaccessible: div pretending to be a button -->
<div class="btn" onclick="submitForm()">Submit</div>

<!-- Accessible: real button element -->
<button type="submit" class="btn">Submit</button>

<!-- Inaccessible: unlabelled input -->
<input type="email" placeholder="Enter your email"/>

<!-- Accessible: labelled input -->
<label for="email">Email address</label>
<input type="email" id="email" placeholder="priya@example.com"/>

Images and Alt Text

Every image that conveys information needs an alt attribute describing what it shows. Decorative images (those that don't add meaning) should have an empty alt="" so screen readers skip them. Avoid putting text in images — users who zoom or switch to high-contrast mode lose that text.

Error Messages That Actually Help

WCAG requires that error messages identify the field in error and describe what happened in text (not just red colour, which is invisible to colourblind users). They should also suggest how to fix the problem — "Email address is required" is less helpful than "Please enter a valid email address, for example: priya@example.com".

Accessibility in React Native

React Native exposes the platform's native accessibility APIs through props:

// React Native accessible button
<TouchableOpacity
  accessible={true}
  accessibilityLabel="Confirm appointment"
  accessibilityHint="Double tap to confirm your booking"
  accessibilityRole="button"
  onPress={handleConfirm}
>
  <Text>Confirm</Text>
</TouchableOpacity>

accessibilityLabel is what screen readers (VoiceOver on iOS, TalkBack on Android) announce to the user. accessibilityHint provides additional context about what will happen when the element is activated. accessibilityRole tells the screen reader what type of element this is.

Where to Start: The Accessibility Audit

If you're adding accessibility to an existing product, prioritise in this order:

  1. Run an automated scan with axe DevTools or Lighthouse Accessibility. Automated tools catch roughly 30-40% of issues — but they catch the easy ones fast.
  2. Do a keyboard-only navigation test. Tab through every interactive element. Can you reach and activate everything? Is the focus visible?
  3. Check all colour contrast ratios. Fix every failure.
  4. Verify all images have appropriate alt text.
  5. Test with a screen reader (VoiceOver on macOS/iOS, TalkBack on Android, NVDA on Windows). Listen to how your product sounds — this is the most illuminating test you can do.

Accessibility isn't a feature you add; it's a quality dimension you maintain. Teams that integrate accessibility checks into their definition of done — alongside functional testing and performance budgets — ship better products consistently, not just in accessibility terms but in clarity, usability, and reliability.

If you'd like an accessibility review of your product, reach out — we offer structured audits with prioritised remediation recommendations.

← Back to Blog Next: Cutting AWS Bills by 40% →︎