For many Indians with disabilities, a bank app that cannot be read by a screen reader or a form that cannot be completed with a keyboard is not a minor inconvenience. It is the difference between managing money independently and depending on someone else.

India’s legal framework has been moving toward treating digital access as a right. At the center is the Rights of Persons with Disabilities (RPwD) Act, 2016. This guide explains what the Act says about information and communication technology, who it affects, and how UX teams can respond. It is general information, not legal advice, so please confirm specifics with a qualified lawyer.

What Is the RPwD Act?

The Rights of Persons with Disabilities Act, 2016 replaced the earlier Persons with Disabilities Act of 1995 and came into force in 2017. It aligns India’s law with the UN Convention on the Rights of Persons with Disabilities, which India ratified in 2007.

Several changes mattered for design and technology teams:

• A wider definition of disability, recognizing 21 conditions
• A rights-based approach, moving away from a purely welfare-based model
• Equality and non-discrimination duties across public life
• A dedicated chapter on accessibility, covering the physical environment, transport and information and communication technology (ICT)

What the Act Says About Accessibility

The accessibility provisions sit in a dedicated chapter of the Act. In simple terms:

• Standards for accessibility. The Central Government is expected to formulate standards covering the physical environment, transportation, information and communications, and other facilities and services provided to the public.
• Access to ICT. Governments are expected to take measures so that content is available in accessible formats, such as audio, sign language and captioned formats, and so that everyday electronic goods and equipment follow universal design.
• Service providers, public and private. The Act expects service providers, whether governmental or private, to deliver services in line with the accessibility rules within a set time after those rules are notified, with provision for extensions in certain categories.
• Penalties. Contravening the Act or its rules can attract fines, with higher penalties for repeated contraventions.
• Complaint mechanisms. The Chief Commissioner and State Commissioners for Persons with Disabilities have roles in handling complaints and monitoring implementation.

The Act does not spell out technical web standards such as “meet WCAG 2.1 AA.” It sets the legal duty and leaves technical detail to rules, guidelines and standards.

From Law to Standards: What Teams Actually Build To

Because the Act itself is not a technical specification, teams rely on recognized standards.

WCAG as the global benchmark

The Web Content Accessibility Guidelines (WCAG) from the W3C are the most widely used technical reference. Level AA is the common target. They are organized under four principles: content must be perceivable, operable, understandable and robust.

GIGW for government websites

For government websites and apps, India has its own Guidelines for Indian Government Websites (GIGW), whose current version aligns accessibility requirements with WCAG 2.1 Level AA. If you work for or with a public body, GIGW is effectively your checklist.

Other standards and campaigns

India has also developed national accessibility initiatives, including the Accessible India Campaign, and the Bureau of Indian Standards has worked on ICT accessibility standards. Standards continue to evolve, so check which ones apply to your sector.

Courts Are Raising the Stakes

Indian courts have increasingly treated accessibility as a fundamental concern, not a nice-to-have. Recent Supreme Court decisions have pressed the government to frame meaningful, enforceable accessibility rules, and have recognized access to digital services, including processes such as online identity verification, as part of the right to life and dignity under the Constitution.

Treat this as direction of travel, not a checklist. The details of specific judgments and resulting directions matter, and legal counsel can tell you how they affect your sector. For product teams, the practical message is clear: inaccessible digital services carry growing legal, reputational and business risk.

Who Should Pay Attention?

• Government bodies and public sector units, which face the clearest expectations
• Banks, fintech and insurance companies, whose services involve identity checks, payments and sensitive forms
• E-commerce and travel platforms, where checkout and booking flows must be operable by everyone
• Edtech and healthcare providers, where inaccessible content can block learning and care
• Telecom, utilities and other service providers that serve the public at scale
• Agencies and vendors building digital products for any of the above, since accessibility requirements pass through contracts

The Business Case Beyond Compliance

• Market reach. India has a large population of people with disabilities, along with older adults who benefit from accessible design.
• Usability for everyone. Clear labels, strong contrast, captions and keyboard support help people on small screens, in bright sunlight or on slow connections.
• Lower support costs. Accessible forms and clear errors reduce failed submissions and help-desk calls.
• Brand trust. Organizations seen as inclusive earn goodwill, while public complaints about inaccessible services travel fast.

Our guide to inclusivity and accessibility in experience design explores these benefits and the principles behind them.

How to Prepare: A Practical Roadmap

1. Map your obligations

Identify whether you are a government body, a regulated entity or a private service provider, and which sector rules apply. Ask legal counsel which standards and directions are relevant, and document the answer.

2. Choose a standard

For most teams, WCAG 2.1 AA is the sensible minimum, and WCAG 2.2 AA is a stronger target because it adds criteria for focus visibility, touch target size and accessible authentication. Government projects should also follow GIGW.

3. Audit what exists

Combine automated tools with manual checks, keyboard testing and screen reader testing, because automated scans catch only part of the problem. A structured review, as described in our guide to identifying design flaws with a UX audit, helps you record each issue with its location, severity and a recommended fix.

4. Prioritize critical journeys

Start with the flows that matter most: sign-up, login, KYC, payments, checkout, bookings, applications and grievance forms. Barriers here exclude people from essential services.

5. Build accessibility into your design system

Fix patterns once, at the component level: buttons with visible focus, form fields with labels and clear errors, accessible modals, color tokens that meet contrast ratios and tables that read well with assistive technology. A shared design system and component library means every new screen inherits accessible behavior.

6. Think India-first

Design for the context your users actually have: multiple languages and scripts, low-bandwidth connections, entry-level phones, voice and vernacular input and varying digital literacy. Accessibility and inclusion overlap heavily here.

7. Test with people who use assistive technology

Include users with disabilities in research. They find issues no checklist reveals and confirm whether fixes actually work. A regular program of usability testing and feedback loops keeps accessibility from becoming a one-time project.

8. Document, publish and maintain

Publish an accessibility statement describing your standard, known limitations and a way to report barriers. Respond to reports quickly, record fixes and re-audit regularly, because accessibility regresses as products change.

Common Mistakes to Avoid

• Assuming the law only applies to government
• Treating an automated scan as proof of compliance
• Relying on overlay widgets instead of fixing underlying design and code
• Ignoring mobile apps, where most Indian users interact with services
• Forgetting PDFs, scanned documents and videos without captions
• Making KYC, OTP and CAPTCHA steps inaccessible
• Fixing screens one at a time instead of fixing shared components
• Skipping regional languages and testing only in English
• Leaving accessibility to the last sprint before launch
• Never testing with real users with disabilities

A Quick Checklist

• Do we know which laws, guidelines and sector rules apply to us?
• Have we adopted WCAG 2.1 AA (or 2.2 AA) as our standard?
• Have we audited critical journeys with automated, keyboard and screen reader checks?
• Are identity verification, OTP, payment and form flows accessible?
• Is accessibility built into our design system and release process?
• Do we have an accessibility statement and a working feedback channel?
• Have users with disabilities tested our key flows?

Bringing It All Together

The RPwD Act sets a clear direction: public and private services should be usable by people with disabilities, including in the digital world. The technical detail comes from standards such as WCAG and GIGW, and from a legal landscape that continues to develop through rules and court decisions.

For UX and product teams, the practical response does not depend on every legal detail. Adopt a recognized standard, audit honestly, fix critical journeys first, build accessibility into your components and keep testing with real users. Start this week by completing your most important flow with only a keyboard and a screen reader. What you find will tell you where to begin.

If you want help making your product accessible and inclusive, work with a trusted UI UX design company in Bangalore that can help you audit, redesign and test experiences that work for every user.