GIGW 3.0 is the Government of India’s rulebook for government websites and apps. It has 88 checkpoints in four areas: quality, accessibility, cybersecurity and lifecycle management. This checklist groups them by area and shows how we test each one: with a tool, by hand, or both.
If you need a site built to these rules, see GIGW-ready websites.
Clause numbers such as 5.1.10 are from the GIGW 3.0 manual. We checked each one against the manual and the official conformity matrix on 5 October 2026.
What GIGW 3.0 is, and who must follow it
- Who wrote it. The National Informatics Centre (NIC) wrote the first GIGW in 2009 and GIGW 2.0 in 2019. Version 3.0 was written with STQC and CERT-In (introduction).
- Who must follow it. All websites and apps owned by government organisations, at central, state, district and local level. Browser-based intranet apps are advised to follow it too (scope).
- What it covers. Websites, web portals, web applications and mobile apps.
- What it leads to. It is the basis of STQC’s Certified Quality Website (CQW) mark. STQC says both government and private websites may apply.
What changed from GIGW 2.0
From the official new features page:
- WCAG 2.1 Level AA replaces WCAG 2.0. That adds 17 success criteria, mostly for low vision, cognitive disabilities and mobile use.
- A cybersecurity chapter, written by CERT-In. It draws on OWASP ASVS, the OWASP Top 10, ISO 27001 and the CIS benchmarks.
- A clearer structure. Each checkpoint lists what the department does, what the developer does and how the evaluator tests it.
- Integration with national platforms, such as India Portal, DigiLocker, Aadhaar-based identity, single sign-on, MyGov and myScheme (5.1.22).
The 88 checkpoints split into 25 quality, 50 accessibility, 3 cybersecurity and 10 lifecycle items (STQC and NIC roadmap).
How to use this checklist
Each row says how we test the item:
- Tool. An automated check, such as axe, Lighthouse, an HTML validator or a link checker. It is fast and repeatable. It finds missing things well, but it can’t judge whether alt text or a label makes sense.
- Manual. A person with a keyboard, a screen reader, or the policy documents.
Keep the evidence as you go. STQC’s evaluator reviews the department’s Website Quality Manual (WQM) and the security audit certificate and report. They also test the site and audit the back-end processes the WQM describes (handbook, §4.4). So save dated tool reports, screen-reader notes, the approved policies and the content approval trail.
The checklist
1. Identity and mandatory pages
| Item | What to check | How we test | Clause |
|---|---|---|---|
| Emblem or logo | Shown on the homepage in the right ratio and colour, with alt text | Manual | 5.1.1 |
| Ownership | Department name in the header or footer of every entry page | Manual, sample of pages | 5.1.2 |
| Last updated | Date shown on the homepage | Manual | 5.1.5 |
| About us, Contact us | Contact details of key officials, linked from the homepage | Manual | 5.1.9, 5.1.10 |
| Feedback | Online form, plus a process to reply on time | Manual: send a test entry | 5.1.11 |
| Help | Linked from every page | Tool: crawl for the link | 5.1.14 |
| National Portal | Prominent link from the homepage | Manual | 5.1.12 |
| Minimum content | Homepage: services, contact, feedback, search or sitemap, terms. Inner pages: title, home link, parent link, owner, contact link | Tool crawl, then manual | 5.1.18 |
| Policies | Copyright, hyperlinking, privacy and terms published. Content, archival and review policies approved | Manual: read each one | 5.4.3, 5.3.3 |
| Domain | gov.in or nic.in (edu.in, res.in or ac.in for eligible institutions) | Manual | 5.1.21 |
| Downloads | Title, size and format shown for each file | Tool crawl | 5.1.6 |
| Brand identity | DBIM colours, type and icons, for central government sites | Manual, against the DBIM toolkit | DBIM, 5.1.23 |
| Accessibility statement | Not a numbered clause. We publish one with our test results | Manual | W3C WAI |
MeitY launched the Digital Brand Identity Manual (DBIM) in February 2025 (PIB). STQC says it must be implemented together with the latest GIGW (STQC).
2. Bilingual content
| Item | What to check | How we test | Clause |
|---|---|---|---|
| Two languages | Bilingual, with a prominent language switch | Manual | 5.4.10 |
| Unicode | Hindi stored as Unicode text, not a legacy font encoding | Manual: paste Hindi text into search. Legacy-font text turns to gibberish | 5.4.10 |
| Parity | Both languages updated at the same time | Manual: compare key pages; check the CMS workflow | 5.4.6 |
| Fonts | Hindi renders without layout breaks on popular browsers | Manual: Chrome, Firefox, Safari, Edge, Android | 5.1.13 |
| Language tags | Page language set; Hindi passages on English pages marked | Tool (axe), then view source | 5.2.38, 5.2.39 |
3. Accessibility (WCAG 2.1 AA)
Checkpoints 5.2.1 to 5.2.50 each map to a WCAG 2.1 success criterion. These are the ones we test hardest.
| Item | What to check | How we test | Clause (WCAG) |
|---|---|---|---|
| Keyboard | Everything works by keyboard. No traps. Focus is visible and in a sensible order | Manual: unplug the mouse | 5.2.21, 5.2.22, 5.2.29, 5.2.33 (2.1.1, 2.1.2, 2.4.3, 2.4.7) |
| Skip link | A way to bypass repeated menus | Tool, then manual | 5.2.27 (2.4.1) |
| Screen reader | Every control has a name, role and state. Status messages are announced | Manual: NVDA on desktop, TalkBack on Android | 5.2.49, 5.2.50 (4.1.2, 4.1.3) |
| Alt text | Every meaningful image has a text alternative that serves the same purpose | Tool finds gaps; a person judges the text | 5.2.1 (1.1.1) |
| Contrast | 4.5:1 for text, 3:1 for large text, icons and control borders | Tool, plus a contrast checker for text on images and hover states | 5.2.14, 5.2.18 (1.4.3, 1.4.11) |
| Zoom and reflow | Works at 200% text size and at 320 CSS pixels wide | Manual: browser zoom to 200% and 400% | 5.2.15, 5.2.17 (1.4.4, 1.4.10) |
| Text spacing | Nothing breaks with wider line, letter and word spacing | Manual, with a spacing bookmarklet | 5.2.19 (1.4.12) |
| Forms | Labels, errors described in text, and a review step before payments or legal submissions | Manual | 5.2.44 to 5.2.47 (3.3.1 to 3.3.4) |
| Video | Captions, and audio description where needed | Manual | 5.2.3 to 5.2.6 (1.2.2 to 1.2.5) |
| Titles and headings | Each page has a clear title; headings describe the section | Tool, then manual | 5.2.28, 5.2.32 (2.4.2, 2.4.6) |
| Documents | PDFs are accessible, or the content is also in HTML | Manual: PDF accessibility check | 5.4.9 |
4. Security
| Item | What to check | How we test | Clause |
|---|---|---|---|
| Security audit | Audit clearance certificate from NIC, STQC or an empanelled lab before going live | Department arranges it; we fix each finding and retest | 5.3.1 |
| Known risks | No OWASP Top 10 issues; follow OWASP ASVS for web and MASVS for apps | Our own scan before the audit | 5.3.1 |
| Updates | CMS, plugins and libraries on current versions | Tool: dependency audit | 5.3.1 |
| Server banners | HTTP response headers don’t reveal software versions | Tool: read headers with curl | 5.3.1 |
| HTTPS | HTTP disabled, HTTPS and HSTS on, old protocols (TLS 1.0, 1.1) off | Tool: TLS scan | 5.3.2 |
| Logs | Kept for a rolling 180 days; clocks synced to NIC or NPL time servers | Manual: config review | 5.3.2, CERT-In |
| Incidents | Listed incidents reported to CERT-In within 6 hours | Manual: check the written process | CERT-In |
| Backups | Stored off the web server; a restore actually works | Manual: restore drill | 5.3.1 |
| Hosting | Data centre and disaster recovery site in different seismic zones | Manual: hosting provider’s documents | 5.3.2 |
| Policies | Security policy, privacy policy and contingency plan approved | Manual | 5.3.3 |
5. Content lifecycle
| Item | What to check | How we test | Clause |
|---|---|---|---|
| Web Information Manager | A senior official is nominated as WIM | Manual: office order | 5.4.1 |
| Approval workflow | Who contributes, moderates and approves, with a record of each approval | Manual: CMS roles and the approval log | 5.4.3 |
| Archival | Old tenders, notices and press releases archived as the policy says | Manual, plus expiry dates in the CMS | 5.1.8, 5.4.3 |
| Broken links | No broken links, no “under construction” pages | Tool: link checker on a schedule | 5.4.7, 5.4.8 |
| External links | Clearly marked when they leave government sites | Tool, then manual | 5.4.4 |
| Language | No spelling or grammar errors; no offensive language | Manual | 5.1.25, 5.4.5 |
6. Mobile apps
GIGW 3.0 says “website/app” throughout. For an app, we check:
- Homescreen. Emblem or logo, ownership and minimum content (5.1.1, 5.1.2, 5.1.18).
- Accessibility. The same WCAG 2.1 criteria. On phones, watch for orientation lock (5.2.10), swipe-only gestures (5.2.34) and shake-to-act features (5.2.37). We test with TalkBack on Android and VoiceOver on iPhone.
- Security. The audit covers mobile apps (5.3.1). The manual points to OWASP’s mobile standard and asks that API calls use encrypted channels.
- Language. Bilingual, with a language choice (5.4.10).
7. Performance and hosting
GIGW 3.0 sets no page-speed number. These clauses still apply:
- Responsive layout, tested on different devices, browsers, connection speeds and screen sizes (5.1.13, 5.1.15).
- Downloadable files kept small for people without fast internet (5.1.6).
- Readable with stylesheets off, and prints on A4 paper (5.1.16, 5.1.20).
- High-availability hosting, backups and disaster recovery (5.3.1, 5.3.2).
Our own target, not a GIGW rule: a Lighthouse mobile performance score of 95 or more on the main page templates.
Our one-day test routine
We test each page template, not every page. In this order:
- Crawl. List every template. Run a link checker and the W3C HTML validator. Check minimum content on each template.
- axe and Lighthouse. Run both on each template, on mobile settings.
- Contrast checker. Text on images, hover and focus states, and charts. Tools often miss these.
- Keyboard. Every template with the mouse unplugged.
- NVDA. Headings, landmarks, forms, tables and the language switch. TalkBack too, if there is an app or a heavy mobile audience.
- Zoom and spacing. 200% and 400% zoom, then the text-spacing check.
- Hindi. Switch language on each template. Check parity, fonts and language tags.
- Security basics. Response headers, HTTPS redirect, HSTS and the TLS scan.
- Report. One dated line per clause: pass, fail or not applicable, with a screenshot for each fail. This goes into the evidence pack.
Who does what
| Who | What they do |
|---|---|
| Department (owner) | Nominates the WIM. Approves the policies. Supplies and approves content. Prepares the Website Quality Manual and applies to STQC. |
| Developer (us) | Builds to the checkpoints. Publishes the citizen-facing policies. Sets up CMS roles for the approval workflow. Fixes audit findings. Keeps software updated. |
| Hosting provider | Multi-layer security, regular backups and disaster recovery (handbook §4.3). |
| Security auditor | NIC, STQC, or a lab empanelled by STQC or CERT-In. Audits the site or app and issues the clearance certificate before go-live (5.3.1). |
| STQC evaluator | Reviews the WQM and the security certificate, tests the site and audits back-end processes. Awards the CQW mark. |
A developer cannot make a site “GIGW certified”. STQC certifies the department’s website. We build to the checklist and hand over the evidence. We are not an auditor, so the security audit stays independent.
Need a GIGW-ready website?
We build government and institutional websites to this checklist, in Hindi and English, and hand over the test report with the code. See GIGW-ready websites or our website development service.
Clause numbers checked against the GIGW 3.0 manual and the official conformity matrix on 5 October 2026. The sources are listed below.