You spent six months and a real budget getting your platform to WCAG 2.2 AA. Your audit report is clean. Then a disability rights commissioner in India flags your site. The notice cites the RPwD Act. You realize WCAG conformance and Indian accessibility law were never the same thing.

TL;DR: WCAG 2.2 conformance and RPwD Act compliance are not the same. A clean WCAG audit does not protect you from legal action under India's disability statute. Indian enterprises need one audit framework. It must satisfy WCAG, GIGW, and RPwD at the same time. Findings must map to each layer.

Key Takeaways: - Conformance to a voluntary W3C standard is not the same as compliance with a statutory obligation. The distinction carries real legal weight in India. - The RPwD Act, 2016 references "appropriate measures" without naming WCAG. A regulator can read gaps outside WCAG success criteria as non-compliance. - GIGW 2.0 and VPAT sit on top of WCAG. A unified audit that maps all three is the only defensible posture for Indian digital properties.

Six months of work and a clean conformance report. Every checkbox green. Then a notice arrives.

This is the moment most Indian CTOs discover the truth. WCAG 2.2 conformance and Indian accessibility law were never built to do the same job. The Web Content Accessibility Guidelines are a voluntary technical standard published by the W3C. They are widely cited. They are not a law.

The Rights of Persons with Disabilities Act, 2016 is a statute. It carries legal, financial, and reputational consequences. These exist independent of any WCAG audit result. When a commissioner in India reviews your digital property, the question is not "did you pass WCAG?" The question is: "did you provide reasonable accommodation in your digital services?" The statute requires that answer.

The two questions can produce different answers. They often do.

Consider a banking app that scores 100% on WCAG 2.2 AA automated checks. It still fails the RPwD test if its KYC flow has no regional language support. It fails if its authentication times out before screen reader users finish. It fails if its error messages go unannounced.

None of those gaps are WCAG violations. All of them are potential statutory failures.

CTOs who treat a clean WCAG report as a compliance shield face enforcement actions. No amount of conformance scoring can defend against them.

The WCAG score measures technical conformance. The RPwD Act measures the experience of a disabled user trying to access a service. These are not the same evaluation.

A similar pattern plays out in adjacent regulated industries. In those industries, a passing QA cycle does not satisfy the regulator either.

So if WCAG is the global standard everyone cites, what is the Indian framework missing? Why does it matter for your next release cycle?

Conformance and compliance sound the same. They are not. - Conformance means meeting a technical standard. WCAG 2.2 is the main example. - Compliance means satisfying a legal obligation. RPwD Act, ADA Title III, Section 508. The statute, not the spec.

In India, WCAG conformance is voluntary. There is no penalty for failing it. RPwD Act violations carry penalties.

Your conformance score is legally irrelevant if the statute is breached. A plaintiff or a regulator does not care that your conformance report was perfect last quarter. They care that the disabled user could not complete a transaction yesterday.

This is the two-track problem in one line. A WCAG audit answers a technical question. The law asks a different one.

You need an audit that answers both at once.

Most organizations discover this distinction only after a complaint. That is the most expensive moment to learn it. Remediation under enforcement pressure costs more and takes longer. It produces worse engineering decisions than planned remediation. If you wait for the notice, you have already lost the planning window.

What new WCAG 2.2 criteria are already showing up in Indian enforcement actions? Which ones hit mobile users first?

WCAG 2.2 introduced nine new success criteria. Two of them stand out: Focus Visible (2.4.11) and Target Size Minimum (2.5.8). They are already showing up in accessibility complaints tied to the RPwD Act. Both directly affect how mobile and cognitive users navigate Indian digital properties.

A focus ring that disappears. A tap target under 24 by 24 CSS pixels. A touch button placed too close to a navigation control.

These look like minor visual issues in a design review. They are the next enforcement front for Indian digital services, particularly in BFSI and government.

The technical gap is real. But there is a second, equally important gap in the documentation layer most teams never address.

WCAG 2.2 is a floor, not a ceiling. The Indian accessibility stack adds two more layers on top.

The Guidelines for Indian Government Websites (GIGW) 2.0 were published by the National Informatics Centre. They add requirements that go beyond WCAG: - Bilingual content handling for English and an Indian language of the user's choice. - Indian language font support, including Devanagari, Tamil, Bengali, and other scripts. - Government-specific usability patterns, including consistent navigation across ministry and department portals.

A WCAG-only audit misses all of these. A page can be perfectly conformant and still fail GIGW.

The language selector may be hidden. The regional language text may wrap incorrectly. The government branding may not match the prescribed pattern.

A VPAT, or Voluntary Product Accessibility Template, is a different document. It is a self-disclosure artifact used in procurement. It tells a buyer, in standardized form, how your product meets accessibility standards. Procurement officers, especially in BFSI and government, ask for it before signing contracts.

It is not a regulatory certificate. Regulators ask for it alongside statutory compliance evidence, not instead of it.

The RPwD Act references "appropriate measures" without naming WCAG. This matters more than it sounds. A regulator can read accessibility gaps outside the WCAG 2.2 success criteria as non-compliance.

If your screen reader flow fails a low-vision user in Tamil, the regulator can call that a failure of the statutory obligation. Tamil support is not in WCAG's success criteria. The statute still applies.

For Indian digital properties serving government, BFSI, or public-facing users, the practical consequence is clear. WCAG 2.2 AA is the floor. GIGW and RPwD sit on top of it. Knowing the stack exists is one thing. Using it inside a delivery cycle is where most engineering teams stall.

One audit. Three frameworks. Zero redundancy.

Here is the structure that works in regulated Indian environments.

Map your digital properties against three layers before the auditor opens a single ticket: - WCAG 2.2 AA success criteria, the technical floor. - GIGW 2.0 specific clauses, including language handling, Indian script support, and government interface patterns. - RPwD Sections 44 to 46. These cover reasonable accommodation. They also cover non-discrimination in digital services. They cover the obligation to provide accessible services.

The intersection of all three is your real audit scope. An audit that checks only layer one does about a third of the work. It produces a report that satisfies none of the regulators who will eventually read it.

Automated scanning has a ceiling. Industry-standard automated tools catch only a limited set of WCAG issues reliably. Most of these are markup and contrast checks.

They catch none of the GIGW or RPwD-specific requirements. They miss semantic structure. They miss focus order. They miss error recovery. They miss screen reader announcements. They miss every interaction that depends on regional language support.

Combine three testing modes: - Automated scanning for regression coverage and baseline conformance scoring. - Manual assistive technology testing with NVDA, JAWS, VoiceOver, and TalkBack across real devices. - Cognitive walkthroughs with Indian users in regional languages, which no automated tool can replace.

A WCAG-only audit skips the last two entirely. That is the gap.

Produce three documents, mapped to three audiences: - A VPAT/ACR for procurement teams evaluating your product. - A GIGW conformance statement for government-facing assets. - An RPwD compliance report mapped to specific statutory sections, not just to WCAG success criteria.

A regulator who receives a report that only references WCAG criteria will read it as evidence. The team did not understand the statute. Map every finding to the specific RPwD section it touches. It is the only way the report functions as a legal artifact.

When evaluating an accessibility audit partner for unified compliance, verify four things: - They test against GIGW, not only WCAG. - They deliver a VPAT as a standard artifact. - They reference RPwD sections clearly in their findings. - They have worked in BFSI, government, or public-sector environments.

A team that has never tested a government portal cannot evaluate GIGW conformance well. Look for RPwD Act and GIGW audit experience on their track record, not just generic accessibility claims. Compliance is continuous, not a one-time certification.

Done right, this framework produces more than a clean audit report. It changes how your engineering, legal, and product teams make accessibility decisions. So what does that look like when it lands on a CTO's desk?

The downstream effects are where the investment pays off. - Procurement stops being a blocker. A defensible VPAT plus an RPwD-mapped compliance report shortens enterprise sales cycles in regulated verticals. The buyer's accessibility team has what they need on the first pass. - Legal exposure drops. Your accessibility position is anchored in statute. A regulator reading your report sees RPwD sections cited, not just WCAG scores. - Engineering velocity improves. One unified remediation backlog replaces three competing audit lists. Sprint planning becomes predictable. Accessibility firefighting ends. - Board-level reporting becomes straightforward. You can quantify conformance, compliance, and residual risk against three named frameworks. That is the kind of clarity a board can act on. It is the same pattern that turns compliance from a tax into a competitive edge when the framing is right.

Does WCAG 2.2 AA conformance satisfy the RPwD Act in India?

No. WCAG is a voluntary W3C technical standard. The RPwD Act, 2016 is a statutory obligation with penalties. Conformance to WCAG 2.2 does not automatically mean compliance with the RPwD Act. Indian regulators can read accessibility gaps outside WCAG success criteria as non-compliance.

What is GIGW and how does it differ from WCAG?

GIGW (Guidelines for Indian Government Websites) 2.0 is a framework published by India's National Informatics Centre. It builds on WCAG but adds India-specific requirements. These include bilingual content support. They include Indian language font handling. They include government-interface usability patterns that WCAG does not address.

Is a VPAT the same as an accessibility compliance certificate?

No. A VPAT (Voluntary Product Accessibility Template) is a self-disclosure document used in procurement. It describes how a product conforms to accessibility standards. It is not a regulatory certification. It does not replace an RPwD Act compliance posture or a formal audit.

What penalties apply under the RPwD Act for digital accessibility failures?

The RPwD Act carries legal, financial, and reputational consequences for non-compliance. Penalties apply to organizations that fail to provide reasonable accommodation in digital services. Enforcement is independent of any WCAG conformance status.

How often should Indian enterprises re-audit accessibility under WCAG and RPwD?

Accessibility compliance is continuous, not a one-time certification. Best practice is a full audit annually. Run targeted re-testing after any major UI or release change. Add continuous automated scanning to catch regressions between audits.

See how Levitation structures a unified WCAG, GIGW, and RPwD engagement for regulated Indian enterprises.

Research and references cited in this article:

• WCAG 2.2 Compliance: What U.S. Companies Must Know in 2026
• Web Content Accessibility Guidelines (WCAG) 2.2
• WCAG 2.2 in 2026: Why Enterprise UX Must Adapt
• WCAG 2.2 Checklist: Complete 2026 Compliance Guide
• WCAG 2.2 | What’s new & how it improves web accessibility
• Accessibility Audits, Testing & VPAT | WCAG & 508 Compliance
• Section 504 Web Compliance: Audit and VPAT Services for New HHS Rule | Accessible.org
• VPAT Guide of 2026: Voluntary Product Accessibility Template
• VPAT vs WCAG: Key Differences | Bug Tracking Blog @ Bird Eats Bug
• What Is A VPAT / ACR? Guide to WCAG Compliance Reporting - Accessibility.Works
• WCAG Vs ADA - What Are The Differences?
• WCAG Compliance Guide | Standards and Conformance Levels