Last updated on August 26th, 2026 at 09:30 am

Most Viral Tool - SEO Audit Tool  | Reseller Profit Tracker Generator | Freelance Invoice Generator | ADHD Planner Generator

WCAG 2.2: What the New Web Accessibility Rules Mean for Indian Websites

A quiet legal and technical shift is moving through the web, and most Indian businesses haven't been told about it. The international web accessibility standard updated to WCAG 2.2, making a handful of specific requirements practical new obligations. At the same time, India's own disability law — the Rights of Persons with Disabilities Act, 2016 — has been on the books for years, and the government's own accessibility guidelines apply to public-facing digital services.

None of this means you need a compliance department. It means a handful of sensible, mostly technical improvements to your website — many of them things you'd probably want anyway. This guide explains what WCAG 2.2 actually changes, what India's legal landscape reasonably means for a small business website, and gives you a practical checklist. It's the India-focused companion to our general website accessibility guide.

Trending Today- Earn $$$ FREE  | Trending LIFE Quotes | HOT DEBATES | Autograph | FREE PAID Tools | Advertise FREE |

First, the foundation: what WCAG is

WCAG (Web Content Accessibility Guidelines) is the international standard for web accessibility, published by the W3C — the same body that maintains the HTML web standards. It's what courts, regulators, and accessibility professionals reference everywhere.

Its structure is worth a moment because it explains everything that follows: content must be Perceivable, Operable, Understandable, and Robust (the "POUR" principles). Under each principle sit success criteria — testable rules ranked A (lowest), AA (the practical target), and AAA (rarely practical). Most laws and procurement rules require WCAG 2.2 AA.

WCAG 2.2 was published in October 2023 and is the current version. It didn't replace the old rules — it added new success criteria aimed at real-world usability problems: small touch targets, missing focus indicators, and interactions that assume fine motor control.

What WCAG 2.2 actually adds (the changes that matter to you)

Nine new success criteria were added. The ones with real consequences for a typical business website:

1. Target size minimum (2.5.8). Buttons, links, and input fields need a minimum touch/click target of 24×24 CSS pixels (and 2.5.5 recommends ~44×44 to be genuinely thumb-friendly). Practical meaning: those tiny "×", menu-hamburger, and icon buttons on mobile fail this. Make tap targets comfortable — it's better for everyone's thumbs.

2. Focus not obscured (2.4.11 / 2.4.12). When a keyboard user tabs through a page, the visible focus indicator (the outline showing where you are) must not be hidden by a cookie banner, sticky header, or menu. Practical meaning: your fixed header or floating widget shouldn't swallow the focus ring.

3. Focus appearance (2.4.13). The keyboard focus indicator must be clearly visible — a continuous, high-contrast outline around the focused element. The "browser's default blue outline" usually already satisfies this; the failure is sites that remove it for "cleaner" looks.

4. Dragging movements (2.5.7). Actions that require drag-and-drop must have a keyboard alternative (buttons, up/down controls, a click-to-select). Think reordering cards, resizing a widget, moving a slider.

5. Consistent help (3.2.6). If you offer help (chat widget, FAQ popup), it should appear in a consistent place across the site rather than jumping around.

6. Redundant entry (3.3.7). Forms shouldn't ask for the same information twice if an earlier entry is still available (e.g., "email again to confirm" is fine only with an option to autofill).

7. Accessible authentication (3.3.8). This one gets attention: if you have a login, you can't require only a cognitive test (like "type the letters you see" captchas) unless alternatives exist. Copy-pasting a password into a code field counts as an alternative. Practical meaning: use password managers and autofill-friendly logins, and don't make solving a puzzle the only way in.

None of these require rebuilding anything. They're refinements: bigger tap targets, visible focus, keyboard alternatives, sensible forms.

The India angle: what does the law actually require?

India's stance is often misunderstood as "accessibility isn't law here, so we're fine." That's a risky read. The real picture:

• Rights of Persons with Disabilities Act, 2016 (RPwD Act) — India's main disability law. It makes discrimination against persons with disabilities unlawful in public services and requires appropriate accessibility measures under Rule 15. The Act and its rules explicitly cover information services delivered digitally, and central/state government bodies are under active obligation to implement them.
• GIGW (Guidelines for Indian Government Websites) — maintained by NIC, and they now reference WCAG 2.1/2.2 AA as the accessibility bar.
• The direction of travel — accessibility was also explicitly flagged in India's recent digital public infrastructure discussions, and the global trend (the EU's European Accessibility Act, the US ADA position) makes it likely that "indirect" pressure — procurement requirements, bank/insurance digital requirements, and larger-corporate mandates trickling down to vendors and agencies — will only grow.

What this means honestly for a small Indian business: you are very unlikely to be sued tomorrow over web accessibility. But you should treat accessibility like you treat a lease's fine print and GST compliance: it's cheap to satisfy early, expensive to retrofit, and the businesses in regulated sectors (banking, insurance, education, healthcare) and anyone with government tenders have a real, current obligation — plus the moral and market case is that more than a billion people, including India's large disability and ageing populations, are a customer base nobody deliberately turns away.

The practical checklist (India edition)

Run this against your site with the free tools from our accessibility guide (WAVE and axe DevTools in the browser):

Quick wins (this afternoon):

1. Text contrast at 4.5:1 for body text (tool: WebAIM Contrast Checker). This is the most common Class A defect.
2. Alt text on every meaningful image.
3. Proper heading hierarchy (one H1, logical H2/H3) — also an SEO win.
4. Descriptive link text ("Read our pricing", not "Click here").
5. Captions on videos; transcripts where feasible.

WCAG 2.2-specific (this month):
5. Enlarge any tiny buttons/links/targets to at least ~24px (ideally 44px) on mobile.
6. Ensure a visible focus outline on tab (never remove the browser's default outline).
7. Make sure cookie banners, popups, and sticky headers don't block the focused element.
8. Provide click alternatives for any drag-only or slider-only interaction.
9. Check your login/captcha flows don't demand a cognitive puzzle as the only option.

Ongoing (quarterly, fold into your website maintenance checklist):
10. Re-run WAVE after any design change.
11. Test 200% browser zoom and keyboard-only navigation on a phone and laptop.

Frequently asked questions

Is accessibility legally mandatory for my business website in India?
There is no direct "you must be WCAG 2.2 AA or face fines" law for private businesses in India today. But the RPwD Act covers digital services in principle, government-aligned work follows GIGW (which cites WCAG 2.1/2.2), and regulated sectors are increasingly asked for it. Treat it as the obvious, cheap insurance it is.

What's the difference between WCAG 2.1 and 2.2?
WCAG 2.2 adds nine new success criteria on top of 2.1 — target sizes, focus visibility, dragging alternatives, consistent help, redundant input, and accessible authentication, plus a few more. If your site is built to 2.2 AA, you're also satisfying 2.1.

Do I need WCAG 2.2 exactly, or is 2.1 fine?
Build or improve to 2.2 AA. It's backward-compatible, so you get 2.1's requirements too. Any "goal X by date Y" you're asked for will reference the newest version.

I have an accessibility widget — does that count as WCAG 2.2?
Almost certainly not on its own. Overlay widgets don't fix underlying structure, contrast, keyboard flow, or focus states — which is precisely what 2.2 targets. Fix the fundamentals as the accessibility guide explains, and treat a widget as decoration at most.

Is WCAG 2.2 stuff hard or expensive for a small site?
Mostly it's free plugin settings and content habits, not development projects. Tap targets, focus outlines, alt text, and contrast are things anyone can fix in a day — our companion guides show exactly how.

Where should I start if my site is far from compliant?
Start with the highest-impact, lowest-effort fixes: contrast, alt text, heading structure, and descriptive links (they overlap with SEO). Then work through the WCAG 2.2 list above. Fix the fundamentals, then test monthly.

The honest summary

WCAG 2.2 isn't a frightening new law — it's an updated, practical playbook for making websites usable, and its headline changes (bigger targets, visible focus, alternatives to drag, sensible forms) are things you'd notice as a customer yourself. For Indian businesses, the honest position is: no one's knocking on your door next week, but the RPwD Act gives accessibility real legal footing, government-adjacent work already cites WCAG, and the trend is one-way. The cheap move — fix contrast, alt text, headings, targets, and focus on your current site, then check quarterly — makes your site better for every customer and quietly removes an entire category of future risk. That's an easy business decision by any measure.