Skip to content

Accessibility conformance reports in India: what business owners need to know

India's draft RPwD rules would require a signed accessibility conformance report, retested before major changes go live. What businesses should do now.

A giant web browser window as a store entrance, with a wheelchair user, an older woman with a cane and a man with a white cane going up a ramp into it

If your company runs a website, app or software product used in India, there’s a new document to plan for: the accessibility conformance report India’s draft accessibility rules would ask every provider to publish. It says, requirement by requirement, how well your product works for people with disabilities, and a senior person in your company signs it.

The rules are still a draft. But the direction is clear, and the work behind a good report takes time. In this post we’ll explain what the report is, whether it applies to you, what the draft asks for, and what we’d do about it now.

A quick note: everything below is based on draft rules that could change before they are final. This is our practical reading, not legal advice. Check the details for your business with qualified counsel.

What an accessibility conformance report is

Think of it as a report card for accessibility. You take an accessibility standard, go through every requirement, and record whether your product supports it, partly supports it or doesn’t, with a short note on each.

It answers simple questions. Can a blind person using a screen reader sign up? Can someone who can’t use a mouse complete a payment with a keyboard? Is the text readable for someone with low vision? Are your PDFs usable?

In the US and Europe, companies already do this, usually on a template from ITI called the VPAT. The VPAT is the blank form. Filled in with real test results, it becomes the conformance report.

In India, the standard you’d report against is IS 17802. It’s India’s version of the European accessibility standard EN 301 549, which itself builds on WCAG, the web accessibility guidelines your team may already know. IS 17802 goes beyond websites: it also covers apps, documents, software and support material. It adds one India-specific rule: if your product offers an Indian language, it has to be accessible in that language too.

Why this is coming now

The standard isn’t new. The RPwD (Amendment) Rules, 2023, G.S.R. 359(E) already said websites, apps and ICT products “shall comply with” IS 17802. Government websites also follow GIGW 3.0.

What was missing was enforcement. In November 2024, in Rajive Raturi v. Union of India, the Supreme Court struck down Rule 15(1) because its standards were really guidelines, and told the government to write mandatory rules. In July 2026 the government published draft rules for technology, S.O. 3962(E). The conformance report sits at the centre of them.

What Status on 21 Oct 2026
IS 17802 named in the RPwD Rules (G.S.R. 359(E), May 2023) In force
GIGW 3.0 for government websites and apps In use
Supreme Court strikes down Rule 15(1) (8 Nov 2024) Final judgment
Draft ICT accessibility rules, S.O. 3962(E) (16 Jul 2026) Draft, comments closed, not yet final

Does it apply to you?

Probably. The draft covers every organisation that makes, develops, controls or offers ICT to people in India. That includes websites, mobile apps, software, digital documents and online services.

It isn’t limited to companies that sell to government. Private businesses are in. So are companies based outside India, as long as their product is offered to people here. And it doesn’t matter whether you built the product yourself or bought parts of it from suppliers: you’re responsible for what your users get.

What the draft would ask of you

In business terms, the draft asks for six things.

A public report, in two formats. One version for people to read (a web page or accessible PDF) and one for machines (a structured data file). Both are free and published on your website or app. If the two disagree, the readable version counts.

Honest detail, no blanket claims. The report goes requirement by requirement and says how you tested: automated tools, manual checks, testing with assistive technology like screen readers. A line saying “fully compliant” won’t do. The people who tested it are named, with their credentials.

Signed by your own senior person. Your designated nodal officer, or someone at Director or designated partner level, signs the report and is responsible for its accuracy. It’s your company’s signature, so accessibility becomes a leadership question, not just a developer task.

A grievance officer. You name a senior Grievance Redressal Officer in the report, and complaints have to be resolved within 30 days.

Government buying stops for non-compliant products. Government bodies would not be allowed to buy, deploy, upgrade or renew ICT that doesn’t comply. If you sell to the public sector at all, this matters.

Clear timelines, once the rules are final. All the clocks start when the final rules are published, not before:

  • Turnover of ₹500 crore or more: one year to meet a first set of core requirements.
  • Under ₹500 crore: 18 months for the same.
  • Everyone: two years to comply fully with IS 17802.

The draft counts turnover on a group basis, so check at group level.

It’s a cycle, not a one-off

This is the part that’s easy to underestimate. The report isn’t something you write once and file away.

Under the draft, you re-test and update it before you release any major change, meaning one that materially changes how the product works or looks or its accessibility features. If you decide a change isn’t major, you keep a record of why. And even if nothing major changes, you review the report at least every two years.

A loop diagram showing how an accessibility conformance report works under India's draft rules: list what you offer, test in three ways, write the report, get it signed and publish it. Before a major change goes live, the report goes back to testing, and a full review is due at least every 2 years.
Under India’s draft rules, the accessibility report is tested again before every major change goes live, and reviewed at least every 2 years.

So accessibility testing becomes part of every release, like security or performance checks. A good share of the basic checks can run automatically in your build pipeline. The rest needs people.

What we’d do now

You don’t need to wait for the final rules. We’d start here.

  1. List what you have. Websites, apps, customer portals, downloadable documents, help pages, and any third-party pieces built into them like chat widgets, payment screens or PDF viewers.
  2. Ask for evidence. Ask your team or your development partner how accessibility is tested today, and for the results. If the answer is “we haven’t”, that’s useful to know early.
  3. Ask your suppliers too. Request their conformance reports, then check how their component behaves inside your product. Under the draft, leaning on a supplier’s report without checking doesn’t shift responsibility away from you.
  4. Build testing into every major release. Agree what counts as a major change, who decides, and where that decision is recorded.
  5. Decide who signs and who handles complaints. Pick the Director-level signatory and the grievance officer now, so they’re involved from the start rather than handed a report at the end.
  6. Start from the EU template. There’s no India edition of the VPAT. The current version, 2.5Rev, comes in 508, EU, WCAG and INT editions. The EU edition is the closest match to IS 17802, with extra rows for India-specific points like Indian languages. The government’s standards body, BIS, is expected to publish an official format within 90 days of the final rules, so expect to adjust.

How much work is it?

It depends on where you start. A product built with accessibility in mind may need a proper audit, some fixes and a process for keeping the report current. An older product, especially one with lots of scanned PDFs or a custom design system, can need much more remediation before an honest report is possible.

Indian-language support often takes longer than people expect, because it has to be tested with screen readers in each language you offer, not just in English.

The ongoing cost is mostly discipline: testing on each major release, keeping evidence, and a short sign-off step. Once that’s routine, the two-year review is much lighter.

Limits worth knowing

This is still a draft. The final rules could change the scope, the deadlines or the details of the report. Check whether S.O. 3962(E) has been finalised before you plan around its dates.

The report format isn’t fixed yet either, since BIS hasn’t published one.

And no tool makes you compliant on its own. Automated checks catch some issues, but things like whether a screen reader makes sense of a form need a human to test.

In closing

The accessibility conformance report turns accessibility into something your company signs its name to. Start early and it becomes part of how you ship, rather than a scramble when the deadlines start.

At Bluelupin we build websites and apps with accessibility testing built into delivery. If you’d like help getting ready for these rules, talk to us.

Leave a comment

Building something in this space?

Thirty minutes with an engineer, not a salesperson.

Start Your AI Journey