Accessibility is often scheduled after the redesign, after the enterprise deal, or after a complaint. That sequence is becoming expensive.
India's draft 2026 disability rules propose a more operational model: define the standard, test the product, publish the evidence, and repeat the work after major changes. Founders should not wait for the final legal text to learn from that model.
Executive summary
- India published draft accessibility rules on 20 July 2026. They are proposals under consultation, not final obligations.
- The draft covers websites, mobile apps, software, digital content, and other ICT products offered to users in India.
- It would require an Accessibility Conformance Report in both human-readable and machine-readable formats, refreshed after major product changes.
- The business risk is broader than penalties: inaccessible journeys exclude customers, create rework, and can block procurement.
- Start with high-value customer journeys, accessible product primitives, mixed-method testing, and release evidence—not a one-time scan.
What changed in India
The Ministry of Social Justice and Empowerment issued draft notification S.O. 3962(E) on 16 July, with publication in the Gazette on 20 July. The proposal was opened for comments for 30 days. A useful legal summary of the draft explains that it would apply Indian accessibility standards to websites, applications, software, digital documents, and related ICT.
The important change is evidence. Covered establishments would publish an Accessibility Conformance Report, or ACR, free of charge. The report would describe what is fully, partly, or not supported; disclose test methods; appear in an accessible human-readable format and a structured machine-readable format; and be updated when a major product change affects accessibility.
Reporting by ThePrint also highlights a procurement consequence in the current draft: government bodies would be unable to buy, upgrade, or renew non-conforming ICT. The wording can change before adoption, so founders should track the final rule and obtain legal advice for their specific scope. But the product signal is strong already.
A real product failure: KYC that assumes every user can blink
Accessibility failures are not abstract checklist misses. In an April 2025 Supreme Court of India judgment, petitioners described digital KYC flows that required a live photograph with a blink. People with blindness and some acid attack survivors could not complete the step, preventing access to services such as bank accounts and SIM cards.
The camera could work. The server could work. Every screen might load quickly. The product still failed because one critical assumption excluded legitimate customers.
That is why founders should test outcomes rather than isolated screens. Can a keyboard-only user subscribe? Can a screen-reader user recover an account? Can a customer enlarge text without hiding the checkout action? Can someone complete identity verification without one specific physical gesture?
Why this belongs on the product roadmap
The 2026 WebAIM Million found automatically detectable WCAG failures on 95.9% of the world's top one million home pages. That increased from 94.8% in 2025, reversing six years of small improvements. Automated checks only detect part of the problem, so the result is a floor, not a complete measure of inaccessibility.
The business impact appears in four places:
- Customer access. A blocked signup, payment, or support journey is lost demand.
- Sales readiness. Enterprise and government buyers increasingly ask for accessibility evidence before purchase.
- Cost of change. Repairing a shared component early is cheaper than fixing every screen built on top of it.
- Market reach. The European Accessibility Act already covers areas including e-commerce, banking, computers, and smartphones across the EU.
Accessibility is therefore both a quality property and a market requirement. It should be funded like reliability, security, and payments—not treated as optional polish.
A 30-day product plan
- Days 1–5: assign ownership and scope journeys. Give one product leader authority across design, engineering, content, legal, and procurement. Inventory the five journeys most connected to revenue or essential access: signup, identity, purchase, core task, and support.
- Days 6–12: establish a mixed baseline. Run automated checks, then test keyboard navigation, zoom, focus, screen-reader flow, error recovery, mobile orientation, and documents. Include third-party checkout, authentication, and support tools.
- Days 13–20: fix the product system. Correct buttons, forms, dialogs, navigation, contrast, status messages, and content patterns in the shared design system first. One accessible primitive can prevent dozens of regressions.
- Days 21–26: test complete tasks with people. Include users with disabilities, compensate them, and observe whether they can finish real outcomes. The W3C is explicit: tools cannot determine accessibility on their own; human judgment is required.
- Days 27–30: create the evidence loop. Record scope, standards, methods, results, exceptions, owners, and retest dates. Add automated checks and manual acceptance criteria to releases. Draft an ACR structure even if the final Indian requirements do not apply to you.
Risks to avoid
- Treating a draft as settled law. Track the consultation and final notification before making legal claims or deadline commitments.
- Confusing a clean scan with access. Automation cannot judge whether alt text is useful or a workflow is understandable.
- Using an overlay as the strategy. A surface widget does not repair inaccessible product logic, source code, documents, or third-party flows.
- Publishing evidence that goes stale. A redesign, new payment provider, or identity flow can invalidate earlier results.
- Owning only the happy path. Errors, timeouts, password recovery, refunds, and support escalation are part of the product too.
The opportunity is a product that works for more people
Accessibility work improves the same foundations that support clearer UX and resilient delivery: semantic components, predictable navigation, explicit errors, usable forms, readable content, and evidence tied to releases.
It also changes the enterprise conversation. Instead of answering an accessibility questionnaire with promises, a team can show tested journeys, known exceptions, accountable owners, and a current conformance record. That is a stronger signal of product maturity.
Build access into the product, not around it
India's draft rules may change. The direction of travel will not: customers, courts, regulators, and procurement teams expect digital products to work for people with different abilities.
Start with the journeys that matter. Fix shared foundations. Test with both tools and people. Keep evidence current. The result is not merely a lower-risk product—it is a better product available to a larger market.