accessibility as a product decision

Most product teams treat accessibility as something that happens at the end. The feature is built, the design is approved, and then someone asks: “Should we make this accessible?” By then it is too late. Retrofitting accessibility is three to five times more expensive than building it in from the start.

But the real problem is not cost. The problem is that framing accessibility as an add-on means you have already decided who your product is for — and excluded everyone else.

In India alone, the 2011 Census counted 2.68 crore people with disabilities. That is larger than the population of Australia. And that number only covers permanent disabilities. It says nothing about the delivery driver squinting at your app under direct sunlight, the new mother navigating one-handed while holding a baby, or the farmer with thick, calloused fingers trying to tap a 32px button on a budget Android phone.

Accessibility is not charity. It is a product decision with measurable business impact.

The three layers of disability

Most PMs, when they think about accessibility, picture someone who is blind using a screen reader. That is one scenario. Here is the full picture:

Permanent: A person who is deaf, blind, has limited mobility, or a cognitive disability. These are the cases WCAG guidelines were originally written for.

Temporary: A person with a broken arm, post-surgery recovery, an eye infection, or temporary hearing loss. They have the same access barriers as someone with a permanent disability — but for weeks or months instead of a lifetime.

Situational: A person driving and using voice commands. A parent holding a child with one arm. A delivery driver in bright sunlight who cannot read low-contrast text. A farmer whose rough, thick fingers cannot hit small tap targets.

The insight is this: designing for permanent disabilities solves problems for everyone. Closed captions were built for deaf users. Today, 80% of people who use captions are not deaf — they are watching in noisy environments, learning a second language, or scrolling in a quiet office.

This is the curb-cut effect. Sidewalk curb cuts were mandated for wheelchair users. They turned out to be essential for parents with strollers, travelers with suitcases, delivery workers with hand trucks, and cyclists. Designing for the edge expands the center.

Why startups think they can skip this

There are three myths that keep startups from treating accessibility as a real product concern:

Myth 1: “It’s a big-company problem.” Google and Microsoft should think about it. We are too small. This is wrong. When your codebase is 20 screens, adding semantic HTML and keyboard navigation takes days. When your codebase is 200 screens with a custom design system and three years of tech debt, it takes months.

Myth 2: “Our users don’t have disabilities.” You do not know that. Analytics cannot tell you how many people bounced because they could not read your text, navigate your forms, or use your app with assistive technology. The data you have is biased toward people who could use the product.

Myth 3: “We’ll add it later.” You will not. Every feature you build without accessibility creates more retrofit work. The backlog grows. The cost grows. “Later” becomes “never.”

Inclusive design is a methodology, not a feature

There is a critical distinction most PMs miss: accessibility is an attribute of your product. Inclusive design is the methodology you use to build it.

Accessibility asks: “Can a screen reader user complete this flow?” That is a yes-or-no question with testable criteria (WCAG 2.1 AA, for example).

Inclusive design asks: “Who are we excluding by the way we have framed this problem?” That is a broader question. It surfaces not just disability, but literacy level, language, connectivity, device quality, and context of use.

This is the Indian context that Western accessibility guides miss entirely. In India, situational disabilities are not rare exceptions — they are the primary usage condition for hundreds of millions of people. Low-literacy users, users on 2G connections with budget phones, users in bright sunlight, users navigating in languages the app barely supports. If your design process starts with a 25-year-old in Bangalore with a flagship iPhone, you have already excluded most of your market.

The PM’s accessibility checklist

You do not need an accessibility team to ship accessible products. You need a process that catches the obvious failures before they ship. Here is what works:

1. Design phase: Contrast and target sizes. Every design review should check two things: color contrast ratio (minimum 4.5:1 for text, 3:1 for large text per WCAG AA) and touch target size (minimum 44x44px, ideally 48x48px for mobile). These two checks alone catch 40% of accessibility failures. Your designers can check contrast in seconds with browser DevTools or Figma plugins.

2. Development phase: Semantic HTML first. The single highest-impact accessibility decision is using semantic HTML — <button> instead of <div onClick>, <nav> instead of <div class="nav">, proper heading hierarchy. If your engineers write semantic HTML, screen readers and keyboard navigation mostly work for free.

3. QA phase: Keyboard-only test. Before any feature ships, one person should try to complete the core flow using only a keyboard. Tab through the page. Can you reach every interactive element? Can you see where focus is? Can you submit forms? This ten-minute test catches more accessibility bugs than any automated scanner.

4. Release phase: Automated scanning. Run axe-core or Lighthouse accessibility audits in CI. They catch about 30-40% of accessibility issues — the mechanical ones like missing alt text, broken ARIA labels, and insufficient contrast. They miss interaction problems, which is why the keyboard test matters.

5. Ongoing: Include disabled users in research. If your user research panels include zero users with disabilities, your product will have blind spots. Period. Recruit at least one participant with a disability in every usability study of five or more people.

Real examples: Indian products getting it right (and wrong)

Swiggy’s audio directions. Swiggy lets users record audio directions for delivery drivers. The original problem was drivers calling repeatedly for directions in complex apartment layouts. The solution — audio notes — also helps users with limited typing ability, users who speak languages not supported by the text interface, and users whose hands are full. That is inclusive design: solve for one constraint, extend to many.

Swiggy’s “Don’t ring the bell.” A simple toggle. Originally useful for parents with sleeping babies or late-night orders. Also useful for people with sound sensitivity, anxiety disorders, or simply anyone who does not want their parents knowing they ordered food again. A tiny feature, zero engineering cost, massive inclusivity win.

PhonePe’s UPI flow. PhonePe intentionally designed large tap targets and high-contrast text for their UPI payment flow. They knew their users included older adults making their first digital payment, people using the app in outdoor markets, and users on small-screen budget phones. The result: higher completion rates across every user segment, not just the “accessible” ones.

Where most Indian apps fail. Open any Indian travel booking app — MakeMyTrip, Goibibo, Ixigo — with a screen reader. Try to book a flight. You will encounter unlabeled buttons, focus traps in date pickers, and auto-scrolling carousels that are impossible to navigate. These are high-traffic apps from well-funded companies. Accessibility is simply not in their product process.

The business case you will need

At some point you will need to make the business case for accessibility to leadership. Here are the arguments that actually work:

Market size. 2.68 crore people with disabilities in India (Census 2011; actual numbers are likely higher). Globally, 1.3 billion people — roughly 16% of the world population (WHO, 2023). Add temporary and situational disabilities and you are talking about effectively everyone at some point.

Legal risk. The Rights of Persons with Disabilities Act, 2016 (RPWD Act) requires all government and government-funded services to be accessible. The Information Technology Act includes accessibility provisions. If you sell to government, education, or healthcare in India, accessibility is not optional — it is a legal requirement. In the US and EU, the compliance landscape is even stricter (ADA, EAA, Section 508).

SEO and performance. Semantic HTML, proper heading structure, alt text, and clean markup are exactly what search engines reward. Accessibility improvements often directly improve search rankings.

Conversion rates. Every accessibility fix — larger tap targets, clearer text, simpler navigation — improves usability for all users. Teams that prioritize accessibility consistently report 10-20% improvements in task completion rates across their entire user base.

How to start — this week

You do not need permission or a budget to start making your product more accessible. Here is a sequence that works:

1. Audit one critical flow. Pick your highest-traffic flow (signup, payment, search). Try to complete it with only a keyboard. Note every place you get stuck.
2. Fix contrast and target sizes. Run a Lighthouse audit. Fix every contrast and tap-target failure. These are mechanical fixes that take hours, not sprints.
3. Set the standard for new work. Add three rules to your team’s definition of done: semantic HTML, 4.5:1 contrast ratio, 44px minimum touch targets. That is it. Three rules.
4. Add axe-core to CI. One npm package. One pipeline step. Every future PR gets checked automatically.
5. Recruit one user with a disability for your next research study. Just one. Watch them use your product. That single session will teach your team more about accessibility than any guideline document.

Keep going

• WCAG 2.1 Quick Reference — The actual standard, filtered to what matters for web products
• Microsoft Inclusive Design Toolkit — The best free resource on inclusive design methodology, including the permanent/temporary/situational framework
• axe-core — The automated accessibility testing engine. Add it to your CI pipeline
• India’s RPWD Act, 2016 — The legal framework for disability rights in India. Know what applies to your product
• WebAIM Screen Reader Survey — Real data on how screen reader users navigate the web. Read this before designing for assistive technology

Where to go next

• The ethical foundation: Ethical PM — dark patterns, privacy, and the product decisions that define your integrity
• Design principles that include everyone: UX Principles — the design thinking that makes accessibility natural, not bolted on
• Work with designers on this: Working with Designers — how to make accessibility part of the design process, not an afterthought