GIGW 3.0 — what the standard actually requires, from inside an STQC-empanelled lab.

In January this year, a state government IT team in Bhopal received an STQC rejection notice. Their portal had scored 62 out of 100. The website looked fine on Chrome. Rendered cleanly on every browser the department had tested. The STQC reviewers flagged twenty-two issues, sixteen of them accessibility-related, every single one invisible without assistive technology. The department head asked the question that every IT team in this situation asks: "We passed a browser test. Why did we fail an accessibility audit?" This guide answers that question precisely, using the criteria that produced those sixteen failures.

GIGW 3.0 is India's operational standard for government websites. It is also the most misunderstood standard in the Indian public-sector IT space. Departments confuse browser-rendering quality with accessibility. They confuse visual design audits with STQC CQW certification. They run automated scanners and mistake a zero-error report for a pass. None of these things is a GIGW audit. A GIGW audit involves NVDA. It involves keyboard-only navigation through every citizen-service flow. It involves checking 150-page scanned PDFs for OCR text layers that were never there.

What follows is how the audit actually works, from the lab that runs it.

01 · What GIGW 3.0 is and who it applies to

GIGW stands for Guidelines for Indian Government Websites. The standard is issued by the Ministry of Electronics and Information Technology — MeitY — and maintained operationally through the National Informatics Centre. The 3.0 edition, published in 2024, supersedes the 2.0 edition that governed government web properties for nearly a decade. The compliance authority is STQC — the Standardisation Testing and Quality Certification directorate — which operates under MeitY.

Scope is broad. GIGW 3.0 applies to:

• All Central government ministries and departments
• State government websites and portals
• Public Sector Undertakings (PSUs)
• Autonomous bodies and statutory bodies
• Union Territory administrations
• Any government entity operating a public-facing digital property

That is several thousand active portals across India. The compliance mark — the Certificate of Quality Website, or CQW — is awarded by STQC after a successful audit conducted by an empanelled testing laboratory. ITQCR — an independent SBU of Ornate Software Solutions Pvt Ltd — is one of the few STQC SAB SETL-1 empanelled labs authorised to conduct GIGW audits and issue CQW certificates.

The standard covers three components, each assessed separately:

• Accessibility — WCAG 2.1 AA minimum, with an expanding set of WCAG 2.2 criteria in practice
• Quality — content accuracy, currency, governance, contact information, grievance mechanisms
• Usability — navigation logic, search functionality, mobile responsiveness, performance thresholds

One distinction that saves departments considerable confusion: GIGW compliance and website quality are not the same thing. A site can be beautifully designed, fast-loading, and award-winning in visual terms while scoring below certification threshold on GIGW. Compliance means meeting defined testable criteria. Quality means the site actually works for real users — including users with disabilities, users on slow connections, and users reading in Hindi or Bengali or Tamil. The standard demands both.

02 · What changed from GIGW 2.0 to 3.0

The shift from 2.0 to 3.0 is not cosmetic. Eight structural changes distinguish the two versions, each of them auditable and consequential:

• WCAG floor raised from 2.0 AA to 2.1 AA. GIGW 2.0 was built on WCAG 2.0's 61 criteria. GIGW 3.0 moves the floor to WCAG 2.1 AA, which adds twelve new criteria — most of them covering mobile interactions, reflow at small screen sizes, and language-of-parts tagging. STQC reviewers are already incorporating WCAG 2.2 criteria into their review practice, particularly around focus visibility and target sizing.
• Mobile-first requirement added. GIGW 3.0 introduces a separate mobile and responsive testing track. Reviewers check content at 320px viewport width, test touch target sizes, and verify that all citizen-service flows are functional on mobile — not merely rendered.
• Performance floor introduced. Core Web Vitals thresholds are referenced. LCP (Largest Contentful Paint) must be under 4 seconds. INP thresholds are not yet specified in the current edition but are on the roadmap. Sites that looked performant on a fibre connection in Delhi have been rejected after being tested on 4G from Tier-2 cities.
• Security baseline made explicit. HTTPS is now mandatory — not a recommendation. Security response headers are checked: CSP (Content Security Policy), X-Content-Type-Options, X-Frame-Options. Sites still running on HTTP or with misconfigured headers fail the security component outright.
• Bilingual and multilingual support explicitly specified. Central government sites must support Hindi and English at minimum. State government sites must support the state's official language alongside Hindi and English (or at minimum the state language and English). This is now a listed requirement in GIGW 3.0, not an implied expectation.
• Social media integration guidelines added. Embedded social media feeds — Twitter/X widgets, Facebook posts, YouTube embeds — must meet accessibility requirements. An inaccessible embedded feed is a GIGW failure, not merely a third-party limitation.
• Accessibility statement page made mandatory. Every GIGW-covered site must carry a dedicated accessibility statement page using the template prescribed by MeitY. This page must include contact details for reporting accessibility issues, the conformance status, and the date of last accessibility review. Optional in GIGW 2.0. Mandatory in 3.0.
• Browser compatibility test suite updated. The reference browser set now includes current versions of Chrome, Firefox, Edge, and Safari — plus mobile browsers. IE11 testing has been retired from the suite, which eliminates a number of legacy-compatibility constraints but creates new expectations around modern browser features.

03 · The CQW certificate process

The CQW process has eleven steps. Every step is necessary. None of them can be shortcut. Departments that ask whether there is a faster route to certification are, without exception, departments that have not yet understood what the audit is checking. Here is the process exactly as it runs through our lab:

1. Department nominates the URL set for audit. The department selects 10 to 25 representative pages — the homepage, at least one citizen-service flow, the feedback/grievance portal, the sitemap, the accessibility statement page, and a cross-section of content pages in each supported language. The URL set is the audit boundary. Issues on pages outside the nominated set will not appear in the certification report.
2. Empanelled lab receives nomination and schedules the audit team. The lab assigns an audit lead and at minimum one senior reviewer. GIGW audits require a combination of WCAG expertise, government-process familiarity, and proficiency with both NVDA and JAWS. The audit window is confirmed with the department.
3. Automated scan run across nominated URLs. The scanner generates the baseline evidence file — contrast failures, missing labels, absent language attributes, ARIA misuse, broken structure. This step produces the starting list, not the final list. Automated rules cover roughly 32 to 38 percent of GIGW's accessibility criteria.
4. Manual accessibility audit: NVDA and JAWS on desktop; VoiceOver and TalkBack on mobile. The keyboard and screen reader audit covers every citizen-service flow in the nominated URL set. Reviewers test form completion, error recovery, authentication, and document downloads. Both NVDA and JAWS are used because they announce the same content differently often enough to matter. Mobile testing uses real devices — not emulators.
5. Performance and security testing against GIGW 3.0 thresholds. Core Web Vitals measured from a representative Tier-2 connection profile. Security headers inspected. HTTPS enforced. Mixed-content warnings flagged. A single missing security header is a GIGW failure in the security component.
6. Content and usability review: Hindi readability, sitemap, feedback mechanism, accessibility statement. Is the Hindi content readable at an appropriate level? Is the sitemap present and current? Does the feedback mechanism work by keyboard? Does the accessibility statement page follow the MeitY template? Is it dated within the last twelve months? These checks require human review — no tool flags a stale accessibility statement.
7. Audit report compiled, findings mapped to GIGW criteria. Every issue is mapped to the specific GIGW 3.0 criterion it violates, with screenshot evidence, screen reader recording where relevant, and a remediation recommendation. The report is the primary document for the department's engineering team.
8. Department receives findings with remediation recommendations. The lab presents findings in a structured meeting if the department requests it. The remediation window begins. Typical departments need three to six weeks to address all flagged issues, depending on internal development capacity and the volume of PDF documents in scope.
9. Department fixes and re-submits. The department's team addresses the flagged issues and notifies the lab that the nominated URL set is ready for re-review. Partial re-submissions — where only some issues have been addressed — are reviewed but will not result in certificate issuance if uncorrected issues remain above threshold.
10. Lab validates fixes. The lab re-tests the specific criteria that were flagged. New issues introduced during remediation are also noted — it is common for HTML changes to address one issue while inadvertently creating another. The validation review is less intensive than the initial audit but covers every originally-flagged criterion.
11. CQW certificate issued if score meets threshold. If the validated score meets the certification threshold across all three components — accessibility, quality, usability — the lab issues the CQW certificate through STQC's certification system. The certificate carries a validity period, typically twelve months, after which re-certification is required.

04 · What STQC reviewers actually check

Across three years of GIGW audits, ten criteria appear in almost every rejection notice. Not because government IT teams are careless — they are not. Because these failures are structural, often invisible in visual QA, and almost never caught by automated testing alone.

1. Skip navigation link (SC 2.4.1). Absent on roughly 80 percent of government sites we audit. A keyboard user arriving at a ministry homepage must tab through the entire navigation menu — sometimes forty or more links — before reaching the page content. A properly implemented skip-to-main link eliminates this. It is a single anchor tag and one CSS line. It is the most common GIGW failure in absolute terms.
2. Accessible CAPTCHA and authentication (SC 3.3.8, new in WCAG 2.2). Government login pages for citizen service portals — income tax, EPFO, state social welfare portals — frequently use distorted-text or image-grid CAPTCHAs with no audio alternative. A visually impaired citizen cannot authenticate. Under GIGW 3.0 reviewed against 2.2 criteria, this is a critical failure.
3. Image-based text in Hindi sections (SC 1.4.5). Bilingual portals frequently use images for Devanagari headings and banner text. The designers created them because rendering Devanagari reliably across older browsers was genuinely difficult ten years ago. It no longer is. An image of the text "स्वागत है" with alt text "Welcome" fails 1.4.5. A screen reader user who reads Hindi gets the English, not the Hindi. The criterion and the language experience both fail simultaneously.
4. Form labels on feedback and grievance portals (SC 1.3.1, SC 3.3.2). Complaint forms, feedback forms, and citizen registration portals are the highest-traffic interactive surfaces on most government websites. They are also the most consistently broken for screen reader users. Placeholder text is not a label. A visible label element programmatically associated with its input is a label. The distinction matters in every NVDA session we run.
5. Focus indicator visibility (SC 2.4.7, SC 2.4.11). Sticky headers — present on nearly every redesigned government portal — hide the keyboard focus indicator when a user tabs into the content area below the fixed navigation bar. The focused element is entirely obscured by the header. The user has no way to know where they are on the page. This is a 2.4.11 failure in WCAG 2.2 terms and a 2.4.7 failure if the focus ring has also been suppressed.
6. Table structure on notice boards and tender documents (SC 1.3.1). Tables used for layout — not data — without proper markup are a long-standing government website pattern. Tender notice tables, budget allocation tables, and circular summaries are frequently built as CSS-positioned divs or as layout tables without th elements, scope attributes, or captions. Screen readers announce them as undifferentiated content.
7. Language of page not declared (SC 3.1.1). Many ministry sites have <html> elements with no lang attribute, or with lang="en" on pages where the primary content is Hindi. A Hindi-language screen reader user encounters content announced in English pronunciation. The failure is a single missing attribute. It appears in roughly half of all GIGW audits we run.
8. Accessibility statement page absent or non-compliant. GIGW 3.0 requires a dedicated accessibility statement using the MeitY-prescribed template. The page must list the conformance status, known limitations, contact for reporting issues, and the date of last review. Pages that carry only a generic "this site is accessible" sentence, or a link to the IT Act rather than a proper statement, fail the requirement.
9. Grievance portal keyboard accessibility. Every government website has a grievance submission portal — mandated separately under the Centralised Public Grievance Redress and Monitoring System framework. Few of them are operable by keyboard alone. Date pickers that require mouse interaction. File upload controls that open only on click. Confirmation steps that use custom click-only widgets. A citizen who cannot use a mouse cannot file a grievance.
10. PDF downloads (SC 1.1.1, SC 1.3.1). The most common point of failure after the direct visual-accessibility criteria. Circular notices, tender documents, RTI forms, annual reports — the document library of a busy ministry portal can run to several thousand PDFs, most of them scanned images with no underlying text. No tags, no reading order, no alt text for embedded images. The HTML site often reaches threshold. The downloadable documents drag the score below certification threshold almost every time.

For government portals where the PDF document library is the primary compliance risk, AccessSure PDF provides automated PDF accessibility remediation and verification at scale — built specifically for the Indian government document workflow.

05 · Bilingual requirements in practice

GIGW 3.0 is specific about language support. Central government websites must provide content in Hindi and English at minimum. State government websites must support the state's official language alongside Hindi and English — or at minimum the state language and English. This is not a recommendation. It is a listed requirement, audited as part of the quality and usability components.

The GIGW framing of "bilingual accessible" is more demanding than most departments expect. It is not only about translating content. It is about ensuring the accessibility structure is also correct for both scripts — and for both language audiences.

In practical audit terms, this means:

• Language of page declared correctly. A portal where the default content is Hindi must carry lang="hi" on the <html> element. A portal where content alternates between English and Hindi needs lang="hi" applied at the span or paragraph level for every Hindi passage — not just the page level. A screen reader that has been set to Hindi TTS (text-to-speech) will read English passages in Hindi pronunciation unless the language switch is marked in the markup.
• Regional language tagging. Tamil content must carry lang="ta". Telugu must carry lang="te". Marathi, despite using the same Devanagari script as Hindi, must carry lang="mr" so the screen reader applies the correct pronunciation rules. Script and language are not the same attribute.
• Bilingual PDF circulars as a separate problem. The website may be correctly tagged. But when the citizen downloads a bilingual circular — say, a welfare scheme notification in Hindi and English — that PDF is almost certainly a scanned image. No OCR. No text layer. The Hindi content is inaccessible regardless of how well the web page is marked up.
• Where generic tools fail. Most accessibility scanning tools use OCR to verify PDF content. They handle Latin scripts competently. Devanagari, Tamil, Telugu, Gujarati, Bengali, and other Indic scripts are where generic OCR breaks down. The tools report a text layer where there is mangled character output. The document is reported as accessible when it is not.

AccessSure PDF's pipeline supports 13 Indian languages including all major Indic scripts — including correct OCR and PDF/UA tagging for Devanagari, Tamil, Telugu, Gujarati, Bengali, Kannada, Malayalam, Odia, Punjabi, and Urdu. That 13-script capability was built specifically for the bilingual government document problem GIGW 3.0 requires solving.

06 · Common failure patterns, ordered by frequency

Across the GIGW audits our lab has conducted, the following failure patterns appear in order of how frequently they occur across all audited sites. The order is drawn from our actual audit log — not from theoretical priority.

1. Missing skip link / bypass block

   Absent from 80 percent of sites on first audit. The fix is one anchor tag and a few lines of CSS. The impact on keyboard users is immediate and significant — without a skip link, every page visit requires tabbing through the full navigation before the user reaches content.

2. Image-based Devanagari or other Indic-script text

   Banner headings, scheme names, ministry logos with embedded text, and navigation items rendered as images. Even when alt text is provided in English, the accessibility experience for a Hindi screen reader user is broken. The fix requires replacing image text with rendered web fonts — which is now straightforward with Google Fonts supporting the full Devanagari range.

3. CAPTCHA without audio or text alternative

   Image-grid CAPTCHAs and distorted-character challenges appear on login pages across government portals. A visually impaired citizen attempting to authenticate into the Income Tax portal, the EPFO portal, or a state social welfare scheme cannot complete the CAPTCHA without an alternative. Under GIGW 3.0 reviewed against WCAG 2.2's SC 3.3.8, this is a critical-level failure.

4. Feedback and grievance form fields without proper labels

   The most-visited interactive surface on any government portal, and one of the least accessible. Placeholder text used in place of labels. Fields associated to the wrong label through incorrect for/id pairing. Date fields with no guidance on expected format. Error messages that reference field position ("the fourth field") rather than field name.

5. Sticky header obscuring keyboard focus

   A site redesign adds a sticky navigation bar. The keyboard-focus indicator drops behind it when a user tabs from the navigation into the first content element. Entirely invisible. The fix is a scroll-margin-top or scroll-padding-top property — one CSS line — or a JavaScript scroll offset. It is rarely documented as a bug in visual QA because it is invisible to mouse users.

6. Downloadable PDFs not tagged

   Circulars, tender notices, policy documents, annual reports, RTI forms. The document library of an active ministry portal spans thousands of PDFs accumulated over years. Almost all of them are scanned images. No tags, no reading order, no alt text, no document title. Every one is a GIGW failure under SC 1.1.1 and SC 1.3.1.

7. Language attribute unset or incorrect

   A ministry site with primarily Hindi content carrying lang="en", or with no lang attribute at all. The screen reader pronounces Hindi text using English phonology. The site is functionally inaccessible to a Hindi screen reader user despite the content being present. The fix is one attribute value change on the <html> tag plus lang tagging on inline language alternations.

8. Auto-playing slideshow without pause control

   Hero image carousels that rotate automatically — present on the majority of government home pages — without a visible pause, stop, or hide control. WCAG SC 2.2.2 requires that moving content lasting more than five seconds can be paused. Carousels that rotate indefinitely without a control are a Level A failure. They also create a vestibular disturbance risk for users with motion sensitivities.

9. Session timeout without extend option

   E-services portals — tax filing, scheme applications, document submission — frequently implement session timeouts of 15 to 30 minutes with no warning and no extension mechanism. A screen reader user completing a long form takes longer than a sighted user. When the session expires mid-form, all data is lost. SC 2.2.1 requires that time limits can be turned off, adjusted, or extended. This is a Level A criterion.

10. Missing accessibility statement page

    Required under GIGW 3.0. Many sites that were certified under GIGW 2.0 do not have the statement, or carry a page that predates the current MeitY template. The statement must include conformance status, known limitations, contact details, and date of last review. A statement that says "this website strives to be accessible" without any of that content fails the requirement.

07 · GIGW 3.0 and PDF accessibility

GIGW 3.0 is explicit: all downloadable files on a government website must be accessible. Not only the web pages. The entire digital surface — circulars, notices, forms, reports, RTI materials, scheme guidelines, tender documents. For most government portals, this means confronting a document library that has accumulated over a decade or more, the majority of it scanned paper.

The practical problem is specific to the Indian government workflow. When a ministry issues a circular, the traditional process involves signing a physical document and scanning it for distribution. The resulting PDF is an image. There is no text layer. No document structure. No reading order. No alt text for any embedded diagrams or tables. A screen reader user who downloads it gets a blank document — technically a PDF, functionally nothing.

The GIGW reviewer checks PDF accessibility as a standard component of the audit. The check covers:

• Whether the PDF has a text layer (searchable, selectable text — not just an image)
• Whether the document is tagged with a proper structure tree (headings, paragraphs, lists, tables)
• Whether images within the PDF carry alt text
• Whether the reading order in the tag tree matches the visual reading order
• Whether the document language is declared
• Whether the document title metadata is set

For government portals with large document libraries, AccessSure PDF provides automated PDF accessibility remediation at scale. The pipeline achieves a 94.7 percent veraPDF rule pass rate across Indian government document types, and supports 13-language OCR — including all major Indic scripts — for scanned-image PDFs where no text layer exists. veraPDF is the open-source PDF/UA validator used by STQC reviewers; a veraPDF pass rate is the measurable baseline for PDF accessibility in a GIGW audit.

Every GIGW-compliant ministry portal should have a PDF remediation workflow. Most do not. That is why PDF downloads are the single most common point of failure in CQW audits. Departments that address the website and ignore the document library will not get the certificate.ITQCR audit team, from the lab record

The question is not whether to remediate the document library. GIGW 3.0 requires it. The question is how to do it at scale, without manual intervention for every scanned circular. That is the problem AccessSure PDF is built to solve.

08 · Questions government IT teams ask

A GIGW audit is not a report. It is a conversation between a government digital property and the citizens it serves. The CQW certificate is evidence that the conversation is possible.