GIGW 3.0 in Practice: The Checkpoints Teams Miss

Every Indian government website and app is required to comply with GIGW 3.0. Most teams find this out somewhere between the audit and the launch date.

GIGW is the Guidelines for Indian Government Websites and Apps, published by the National Informatics Centre under MeitY. Version 3.0 carries 88 mandatory checkpoints across accessibility, quality, cyber security and lifecycle management, and it is aligned to the Rights of Persons with Disabilities Act 2016, the Harmonised Guidelines on Accessibility, and WCAG 2.1 Level AA. Non-compliance with the RPwD Act carries penalties under Section 89, including fines and, for repeat violations, imprisonment.

This is not advisory. It applies to central and state government sites and apps, and it is audited.

The 88 checkpoints are not the hard part

Read as a list, GIGW is manageable. Most of it is unarguable: publish a contact, date your content, secure your transport, state your copyright, provide a sitemap, own your domain properly.

The difficulty is that a meaningful share of the accessibility checkpoints cannot be satisfied by a page-level fix at the end. They are properties of components, and if the components are wrong, every page is wrong, and remediation becomes a rebuild two weeks before a launch date that will not move.

That is the failure mode we get called into. The audit report arrives, it lists 300 instances, and the instances turn out to be the same six components repeated across the site.

The checkpoints teams actually miss

Keyboard operability, end to end. Not "the site is navigable". Can a keyboard user complete the application? Custom dropdowns, date pickers, file uploads, multi-step wizards, and modals are where this breaks. A modal that traps focus, or worse, does not trap it and lets a user tab into the frozen page behind, fails the moment a tester tries it.

Focus visibility. Somebody removed the outline because it looked untidy. It is a WCAG 2.1 AA failure and a GIGW failure, and it makes the whole site unusable without a mouse. This single line of CSS causes more audit findings than almost anything else.

Error identification and suggestion. A red border is not error identification. The requirement is that the error is described in text, associated with the field, and where the system knows the fix, that the fix is suggested. "Invalid input" satisfies nothing.

Text alternatives that carry meaning. Government sites are full of scanned circulars, notification images, and infographics used to convey policy. An alt attribute reading "notification" fails. If the image carries information, the information must be available as text, and a scanned PDF of a circular is not accessible content.

Language and readable content. Content in Hindi or a regional language must declare its language so a screen reader pronounces it correctly. Mixed-language pages need the language set at element level, not just on the html tag.

Reflow and zoom. Content must remain usable at 400% zoom without horizontal scrolling. Fixed-width tables and layouts built for a desktop breakpoint fail here, and government portals are full of both.

Timeouts. Session expiry on a long form, with no warning and no saved progress, is both a WCAG failure and the reason a citizen gives up. Warn, allow extension, and preserve what they typed.

Do it as components, not as findings

The efficient path through GIGW is not to work the audit report line by line. It is to fix the shared parts.

Build or adopt an accessible component set covering the patterns every government service repeats: form fields with labels, hints and error text wired correctly; date entry; file upload with clear constraints; OTP input; tables that reflow; modals with correct focus behaviour; tabs and accordions with proper roles and states; and a page skeleton with landmarks, a skip link and a visible focus style.

Get those right once and the majority of the accessibility checkpoints are satisfied structurally, on every page, including pages that do not exist yet. This is the difference between passing an audit and being accessible, and only the second one survives the next release.

Prove it, and keep proving it

Automated scanning is a first pass. It will not tell you whether the focus order is sensible, whether the error text is useful, or whether a screen reader user can finish the task.

Run a manual audit against the real journeys. Test with a keyboard alone and with NVDA or JAWS. Put an automated check in CI so regressions get caught at the pull request rather than the next audit cycle. Then write the accessibility statement from what you found, including what is not yet fixed and when it will be, because a statement written from intention is a liability once somebody tests it.

The wider ground is moving the same way. SEBI has set accessibility requirements for regulated financial entities, so this is no longer only a government obligation in India. It is becoming the baseline for anyone operating a serious digital service here.

We build and remediate public-sector software against GIGW and WCAG. If you have an audit coming, we should talk.