India has its own accessibility guidelines for government websites. They are called GIGW — Guidelines for Indian Government Websites. The latest version, GIGW 3.0, explicitly mandates that every government website must be accessible to people with disabilities. It is not a suggestion. It is a requirement.
And yet, as a blind citizen who depends on these websites to access public services, I can tell you with complete certainty: the vast majority of Indian government websites do not follow their own guidelines.
The irony is difficult to overstate. The same government that published these accessibility standards, the same government that signed the UN Convention on the Rights of Persons with Disabilities, the same government that enacted the Rights of Persons with Disabilities Act in 2016 — this government runs websites that I cannot use independently. Every single day.
What Is GIGW 3.0?
For those unfamiliar, the Guidelines for Indian Government Websites (GIGW) are published by the National Informatics Centre (NIC) under the Ministry of Electronics and Information Technology (MeitY). The first version was released in 2009. The latest version, GIGW 3.0, aligns closely with WCAG 2.1 (Web Content Accessibility Guidelines) at the AA conformance level.
GIGW 3.0 covers a wide range of requirements:
- All content must be perceivable, operable, understandable, and robust — the four WCAG principles
- Documents published on government websites must be in accessible formats
- Forms must be properly labelled and navigable by keyboard
- Multimedia content must have alternatives (captions, transcripts, audio descriptions)
- Websites must be compatible with assistive technologies including screen readers
- Websites must undergo accessibility audits and display conformance information
On paper, this is comprehensive. India has, in principle, one of the more progressive frameworks for government website accessibility in the developing world. The problem is not the guidelines. The problem is that almost nobody follows them.
What I Actually Find When I Use Government Websites
I have been working in digital accessibility for over sixteen years. I use a screen reader for every interaction I have with a computer or phone. When I visit a government website to do something as routine as downloading a certificate, checking a policy document, or filing a grievance, here is what I encounter — not occasionally, but consistently.
Scanned PDFs That Are Invisible to Screen Readers
This is perhaps the most widespread and most damaging barrier. Government departments regularly upload documents as scanned image PDFs. These are photographs of paper. My screen reader sees a blank page. There is no text layer, no structure, no reading order. The document might as well not exist.
I am talking about circulars, gazette notifications, application forms, public notices — documents that citizens need to read and act upon. When these are scanned images, every blind or low-vision citizen in the country is excluded. GIGW 3.0 explicitly requires documents to be in accessible formats. This requirement is ignored on a massive scale.
Forms Without Labels
Government websites are full of forms. Apply for a certificate. Register a complaint. File a tax return. Submit a grievance. These forms routinely have input fields with no associated labels. My screen reader lands on a text box and announces "edit text" or "blank." I have no idea whether I am supposed to type my name, my address, my Aadhaar number, or something else entirely.
Sometimes visual labels exist on screen, but they are not programmatically linked to the input fields. The sighted user sees "Father's Name" next to the box. I hear nothing. The fix is straightforward — a proper <label> element with a for attribute. It takes seconds to implement. It is absent on form after form after form.
CAPTCHAs With No Audio Alternative
This one is personal. CAPTCHAs are the gatekeepers of government services. Want to log in? CAPTCHA. Want to download a document? CAPTCHA. Want to check the status of your application? CAPTCHA.
Visual CAPTCHAs are, by definition, inaccessible to blind users. GIGW 3.0 requires an accessible alternative — an audio CAPTCHA, a logical question, or another mechanism that does not rely on vision. On most government portals I have tested, there is no such alternative. The CAPTCHA is a distorted image of text, and I am simply locked out.
I have had to call family members to read CAPTCHAs to me over the phone so I can access services that are supposed to be my right as a citizen. This is not accessibility. This is exclusion with extra steps.
Auto-Playing Videos Without Controls
Some government homepages feature videos that play automatically when the page loads. These videos often have no pause button, no stop button, and no way for a screen reader user to control them. The audio from the video competes with my screen reader's speech output, making the entire page unusable until the video finishes or I find a way to mute my browser tab.
GIGW 3.0, following WCAG, is clear: audio that plays automatically for more than three seconds must have a mechanism to pause or stop it. This requirement is routinely ignored.
Tables Used for Layout
HTML tables have a specific purpose: presenting tabular data with row and column relationships. Government websites frequently use tables to control the visual layout of pages. My screen reader interprets these as data tables and announces "table with 15 rows and 4 columns" when there is no actual data relationship at all. This creates a confusing, disorienting experience where I hear row and column announcements for what is simply a page layout.
Conversely, when actual data tables are used — budget figures, statistical reports, comparison charts — they often lack proper header markup. I hear a stream of numbers with no context for what each number represents.
No Skip Navigation
Skip navigation links allow keyboard and screen reader users to bypass repetitive content — typically the header and navigation menu — and jump directly to the main content. This is one of the simplest accessibility features to implement. A single hidden link at the top of the page.
On many government websites, this link does not exist. Every time I visit a new page, I must tab through the entire navigation menu, every link in the header, every dropdown item, before I reach the content I actually came for. On sites with extensive mega-menus, this can mean pressing Tab fifty or sixty times before reaching the first line of actual content.
Poor Mobile Responsiveness
India's Digital India initiative rightly emphasises mobile access. A significant portion of Indian citizens access the internet primarily through smartphones. Yet many government websites are not responsive. Content overflows the viewport, buttons are too small to tap, and zoom is often disabled — a direct violation of WCAG 2.1's reflow and resize requirements.
For users who rely on screen magnification on mobile devices, a non-responsive government website is effectively unusable.
The Accessibility Widget Trap
In recent years, I have noticed a growing trend on Indian government websites: the accessibility overlay widget. A small icon, usually in the corner of the page, that claims to offer accessibility features — text resizing, contrast adjustment, screen reader compatibility, and so on.
I need to be direct about this: accessibility overlay widgets do not make a website accessible. They are a superficial band-aid that creates an illusion of compliance while leaving the underlying barriers untouched.
Here is why these widgets fail:
- They cannot fix missing form labels. If a form field has no programmatic label, no overlay can create one accurately. The widget does not know what the field is for.
- They cannot fix document structure. If headings are not marked up as headings, if lists are not marked up as lists, the overlay cannot restructure the DOM in a way that makes semantic sense.
- They cannot fix keyboard navigation. If custom components trap focus or have no keyboard support, an overlay running in the browser cannot add it.
- They cannot make scanned PDFs readable. No JavaScript widget can perform OCR on a scanned document and generate an accurate, structured text layer.
- They often conflict with actual assistive technology. Screen reader users already have our own tools for adjusting text size, contrast, and reading preferences. Overlay widgets frequently interfere with screen reader behaviour, creating new problems while solving none of the real ones.
- They create a false sense of compliance. Decision-makers see the widget icon and believe the job is done. It is not. The widget is a cosmetic fix on a structural problem.
Multiple international accessibility organisations, including the overlay fact sheet signed by hundreds of accessibility professionals worldwide, have stated clearly that overlays do not achieve WCAG conformance. Yet they continue to be deployed on government websites because they are easy to install and they look like progress.
Real accessibility requires changes to the source code, the content, the design process, and the development workflow. There is no shortcut, and any vendor claiming otherwise is selling a fiction.
The Certificate Paradox
There is a particular irony that I find difficult to articulate without frustration. The government of India issues disability certificates through its various portals and health departments. These certificates are essential documents — they unlock access to reservations in education and employment, travel concessions, assistive device subsidies, pension schemes, and other entitlements under the RPwD Act.
The websites where a person with a disability must go to apply for, check the status of, or download their disability certificate are themselves inaccessible.
Read that again. A blind person trying to obtain official recognition of their disability from the government is blocked by an inaccessible website. The system designed to serve people with disabilities cannot be used by people with disabilities without sighted assistance.
This is not a minor oversight. This is a structural failure that undermines the very purpose of the service.
What Is Working
I believe in being fair. Not everything is broken, and there are efforts worth acknowledging.
The UMANG (Unified Mobile Application for New-age Governance) app has made meaningful improvements in accessibility over successive updates. While it is not perfect, the app demonstrates that when accessibility is treated as a priority in the development process, real progress is possible. Navigation is more logical, key services are usable with a screen reader, and the team has been receptive to feedback.
Some state-level portal redesigns have incorporated accessibility from the ground up, with proper heading structures, labelled forms, and keyboard navigation. These are exceptions rather than the rule, but they prove the point: it can be done. The knowledge exists. The technology exists. What is often missing is the institutional will.
MeitY's own accessibility guidelines documentation and some of the training initiatives around GIGW awareness have improved. The framework itself is sound. The gap is in implementation and enforcement.
What Needs to Change
I have spent sixteen years evaluating digital products for accessibility. The barriers I find on Indian government websites are not novel or complex. They are well-understood problems with well-documented solutions. Here is what needs to happen.
Mandatory Accessibility Audits Before Launch
No government website or portal should go live without an accessibility audit that includes both automated testing and manual evaluation with assistive technologies. This should be a non-negotiable requirement in every government IT procurement contract. Just as we would not launch a building without a safety inspection, we should not launch a website without verifying it can be used by all citizens.
Include People with Disabilities in Usability Testing
Accessibility is not something you can fully evaluate from the outside. You need people who use screen readers, people who navigate by keyboard, people who use switch devices, people who rely on magnification — actually testing the product during development. Not as an afterthought during a final review, but as a regular part of the design and QA cycle. We find barriers that no automated tool and no sighted tester will catch, because we experience them firsthand.
Stop Relying on Overlay Widgets
Government procurement guidelines should explicitly prohibit the use of accessibility overlay widgets as a substitute for native accessibility. These tools waste public money and create a false sense of compliance. Every rupee spent on an overlay licence is a rupee that could have been spent on fixing the actual code.
Enforce GIGW Compliance with Consequences
Guidelines without enforcement are suggestions. There must be real accountability for non-compliance. This could take the form of mandatory compliance scores tied to departmental performance metrics, public accessibility scorecards, or a designated authority empowered to flag and mandate remediation of inaccessible government websites. The RPwD Act provides the legal foundation. What is needed is the mechanism to act on it consistently.
Procure Accessible Technology from the Start
Accessibility is far cheaper to build in from the beginning than to retrofit. Government IT procurement policies must require accessibility conformance as a mandatory evaluation criterion — not a nice-to-have checkbox at the end, but a disqualifying factor if absent. When government agencies hire vendors to build websites and applications, the RFP must specify GIGW 3.0 and WCAG 2.1 AA conformance as deliverables, tested and verified before final payment.
A Right, Not a Favour
I want to end with something I feel strongly about, because the data and the technical arguments, while important, can obscure the human reality of this situation.
India has over 26 million people with disabilities, according to the 2011 Census — and the actual number is widely acknowledged to be significantly higher. Every one of us is a citizen. Every one of us has the same right to access government services, government information, and government processes as any other citizen.
When a government website is inaccessible, it is not an inconvenience. It is a denial of rights. It forces me to depend on someone else to do something I am fully capable of doing independently, if only the technology were built correctly.
The gap between India's accessibility policy and India's accessibility reality is wide. But it is not unbridgeable. Every barrier I have described in this article has a known solution. The question is whether the institutions responsible for these websites will treat accessibility as the priority it deserves to be.
I remain cautiously optimistic. I have seen progress where there is commitment. But optimism without accountability changes nothing. It is time for Indian government websites to meet the standards India itself has set.
If your organisation is working on government digital services and wants to get accessibility right, I am available to help.