Web Accessibility Checklist: WCAG 2.2 for Indian Businesses

A customer opens your enquiry form on a phone, but a screen reader announces three fields as just "edit text". Another visitor with a hand tremor keeps tapping the wrong tiny link, and a third cannot read your light grey placeholder text in sunlight. None of them tells you; they just leave.

This web accessibility checklist gives you the checks that matter most, written for Indian business sites and apps. It is built on WCAG 2.2, and it shows what to test, how to fix it and what to ask a developer for.

What is WCAG and which version should you follow?

The Web Content Accessibility Guidelines (WCAG) are the international technical standard for accessible web content, published by the W3C. WCAG 2.2 became a W3C Recommendation on 5 October 2023, and the W3C recommends adopting it as your conformance target even where formal rules cite an older version.

Sites that meet WCAG 2.2 also meet WCAG 2.1, because the new version only adds criteria. That makes Level AA of WCAG 2.2 the safest target for a new build. Level A covers only the most basic barriers, and Level AAA is not expected for whole sites.

Is web accessibility a legal requirement in India?

For Indian government sites it is a written rule, and for private businesses it is a growing risk. The GIGW 3.0 guidelines require conformance with WCAG 2.1 Level AA, so any government or public-sector project must meet at least that.

For private firms, the Rights of Persons with Disabilities Act, 2016 requires accessible information and communication technology. In April 2025, the Supreme Court of India held in Pragya Prasun v. Union of India that digital access is part of the right to life under Article 21, and it directed accessible digital KYC processes. Banks, fintech apps and insurers should watch this closely. If you sell to the EU, the European Accessibility Act has also applied to e-commerce and consumer banking services since 28 June 2025. This article is not legal advice, so check your own obligations with a lawyer.

What is new in WCAG 2.2?

WCAG 2.2 adds nine success criteria, six of which are at A or AA level. They matter most for mobile users, keyboard users and people who struggle with passwords. The table lists the ones to check on a typical business site.

The W3C summary of what's new in WCAG 2.2 explains each one with examples. The target size rule has exceptions for inline links, browser-controlled elements and well-spaced small targets, so a small footer link inside a sentence does not automatically fail.

What should a web accessibility checklist include?

A useful checklist groups checks by what the user does, and gives a pass test for each. Use this table on your top five templates, such as home, product or service page, enquiry form, checkout and login.

For Indian audiences, also test mixed-language content. Set the lang attribute correctly, for example hi for a Hindi block, so screen readers pronounce text properly, and make sure your Devanagari or other script fonts stay legible at small sizes.

How do you test accessibility step by step?

Test by hand first, because automated tools find only a share of real problems. A scanner cannot tell you whether an alt text is meaningful or a focus order makes sense.

1. List your key journeys. Pick the five tasks that earn money or leads, such as sending an enquiry, paying and logging in.
2. Run a keyboard-only pass. Try to finish each journey with Tab, Shift+Tab, Enter, Space and arrow keys. Note every trap, hidden focus or unreachable control.
3. Run an automated scan. Use a tool such as Lighthouse or axe DevTools to catch contrast, missing labels and markup errors quickly.
4. Do a screen-reader pass. Try NVDA on Windows, VoiceOver on iPhone or TalkBack on Android for the same journeys.
5. Check zoom and mobile. Zoom to 200%, resize to a narrow window and test tap targets on a mid-range Android phone.
6. Log, rank and fix. Rank issues by how many users they block, fix blockers first and re-test the same journey.

Our guide on fixing poor INP pairs well with this process, because slow, janky interfaces hurt keyboard and assistive-technology users first.

What does an accessibility audit and fix cost in India?

Cost depends on page count, template variety and how many problems sit in shared components. As an indicative range from project experience, not a fixed quote:

Fixing issues inside a shared component library is cheaper than fixing the same problem page by page. That is also why accessibility fits naturally into a design system, where one accessible button or form field is reused everywhere.

How Arham Technology approaches accessibility

Our frontend development service treats accessibility as an acceptance criterion, not polish. Our approach follows the same delivery steps we use for other frontend work:

• Interface inventory: we list your screens, components and journeys, and flag patterns that block keyboard or screen-reader use.
• Foundation pass: we set colour tokens that meet contrast, a visible focus style and accessible base components before building features.
• Feature verticals: we build each journey with labelled fields, clear error states, and loading, empty and error screens that are announced properly.
• Hardening and metrics: we test on mid-range Android hardware, add automated checks to the pipeline and hand over living documentation.

Deliverables include accessible patterns for focus, keyboard and screen-reader flows, a documented component library and typed components in Angular or React. If search visibility matters too, accessibility overlaps with the basics in our technical SEO checklist, and our SEO service covers how the two work together. Choosing a framework also affects how easily accessibility is built in, as our Angular vs React comparison explains.

What should you do next?

Take your enquiry form, put the mouse away and try to submit it using only the keyboard. Write down every place you got stuck, lost the focus outline or could not tell what a field was for. That list is the start of your audit.

If you would like a developer to review it, read about our frontend development service and contact us with the page URLs. We will tell you what we see and what it would take to fix, before you commit to any work.