1. Introduction: Accessible and Compliant Government Digital Services
The Guidelines for Indian Government Websites and Apps (GIGW) and the Web Content Accessibility Guidelines (WCAG) together form the backbone of accessible, usable, secure and citizen-centric digital service delivery in India. GIGW is issued by the Ministry of Electronics and Information Technology (MeitY), Government of India, and produced through the National Informatics Centre (NIC). Its current release, GIGW 3.0 (2023), is deeply harmonised with WCAG 2.1 at Level AA, published by the World Wide Web Consortium (W3C) as the globally recognised technical standard for web and mobile accessibility.
GIGW is not merely an aesthetic style guide. It is a compliance and conformance framework that Government of India departments, ministries, state governments, public sector undertakings (PSUs), autonomous bodies and their vendors are expected to adopt so that public-facing websites, web applications and mobile apps are Universal (accessible to Persons with Disabilities and all demographics), Usable, secure, well-designed and legally defensible. Compliance signals include the GIGW/STQC 'Certified Quality Website' certification and the accessibility conformance mark. WCAG conformance additionally has statutory teeth in India through the Rights of Persons with Disabilities (RPwD) Act, 2016, which mandates accessible electronic and information technology for all persons, and via Rule 15 of the RPwD Rules that references the accessibility standards notified by MeitY (which point to GIGW/WCAG).
This guide is written for two audiences at once: the auditor or assessor who must verify conformance and issue findings against defined success criteria, and the implementer, product owner or development team that must build, remediate and sustain conformance. It walks through the full assessment lifecycle: scoping, requirement enumeration (every WCAG principle, guideline and success criterion plus every GIGW compliance area), the phased implementation approach, the conformance/scoring model, the audit process, evidence collection, roles, KPIs and readiness. We enumerate WCAG's four POUR principles, its 13 guidelines, and all Level A / AA / AAA success criteria families, alongside GIGW's design, content, management, security, mobile-app and quality domains.
Copyright and Licensing Note
WCAG 2.0, WCAG 2.1 and WCAG 2.2 are W3C Recommendations published by the World Wide Web Consortium (W3C) and its Web Accessibility Initiative (WAI), made available under the W3C Software and Document Notice and Licence. GIGW 3.0 is Crown/Government content published by MeitY/NIC, Government of India. This guide is original CyberSigma commentary. Success criterion identifiers (e.g. SC 1.1.1) and guideline titles are cited as factual references only; the normative text of the standards is NOT reproduced here. For binding requirements always consult the official W3C WCAG Recommendation and the official MeitY GIGW document. Certification against GIGW is administered through STQC (Standardisation Testing and Quality Certification), a MeitY body.
2. What is GIGW and WCAG
WCAG (Web Content Accessibility Guidelines) is the international technical standard for making web content and applications accessible to people with disabilities, including visual, auditory, physical, speech, cognitive, language, learning and neurological disabilities. It is organised as a layered framework: four foundational principles, thirteen guidelines under those principles, and testable success criteria (SC) under each guideline. Each success criterion is assigned a conformance level: A (minimum), AA (mid, the near-universal legal/procurement target), or AAA (highest). WCAG 2.0 (2008) contained 61 success criteria; WCAG 2.1 (2018) added 17 to reach 78, focusing on mobile, low-vision and cognitive needs; WCAG 2.2 (2023) added 9 more (and removed one), addressing further cognitive and motor needs. Each SC is supported by non-normative Techniques and Understanding documents.
GIGW (Guidelines for Indian Government Websites and Apps) is MeitY's national framework that operationalises accessibility, usability, security, and quality for Indian public sector digital properties. GIGW 3.0 is structured around a set of compliance areas covering website/app design and architecture, content, accessibility (mapping directly to WCAG 2.1 AA), technology and security, management and maintenance, and mobile application specifics. GIGW compliance is verifiable through a documented checklist and is a precondition for hosting under NIC infrastructure and for the STQC 'Certified Quality Website' and accessibility certifications. In short: WCAG defines the global accessibility 'what' and 'how testable'; GIGW wraps WCAG inside an Indian government-specific quality, security and governance envelope.
| Attribute | WCAG | GIGW |
|---|
| Issuer | W3C / WAI (Web Accessibility Initiative) | MeitY / NIC, Government of India |
| Scope | Web content and applications, globally | Indian government websites, web apps and mobile apps |
| Current version referenced | WCAG 2.1 (2018), WCAG 2.2 (2023) | GIGW 3.0 (2023) |
| Structure | 4 Principles, 13 Guidelines, testable Success Criteria | Compliance areas: design, content, accessibility, security, management, mobile |
| Conformance levels | A, AA, AAA | GIGW compliant + STQC certification; accessibility target WCAG 2.1 AA |
| Legal linkage in India | RPwD Act 2016 accessibility mandate | MeitY policy; referenced for government adoption |
| Certifying body | N/A (self/third-party conformance claims) | STQC (testing & certification) |
3. Who Must Comply
WCAG conformance is expected of virtually any organisation delivering digital services, driven by procurement rules, anti-discrimination law and accessibility mandates across jurisdictions. GIGW compliance is mandated for Indian public sector entities. The following classes of stakeholders fall within scope.
| Stakeholder | Applicability | Typical driver |
|---|
| Central government ministries and departments | GIGW mandatory; WCAG 2.1 AA required | MeitY policy, RPwD Act 2016 |
| State governments and UT administrations | GIGW mandatory for public portals | State IT policy aligned to MeitY |
| Public Sector Undertakings (PSUs) and autonomous bodies | GIGW expected for citizen-facing properties | Parent ministry directive |
| Statutory bodies, regulators, commissions | GIGW and WCAG AA | Public duty, RPwD compliance |
| Vendors / system integrators building govt portals | Must deliver GIGW/WCAG-compliant systems | Contract / RFP clauses, STQC audit |
| Private enterprises (banking, telecom, e-commerce) | WCAG AA increasingly required | RPwD Act, procurement, ADA/EN 301 549 equivalents |
| Educational institutions and universities | WCAG AA for portals and LMS | Equal opportunity, RPwD |
| Any org bidding for government contracts | GIGW/WCAG conformance as eligibility | RFP eligibility criteria |
- Persons with Disabilities (PwD) are the primary beneficiaries whose needs the standards protect — visual, hearing, motor, speech, cognitive and neurological.
- Global legal analogues that make WCAG AA the de facto baseline include Section 508 (US), the ADA, the European Accessibility Act, EN 301 549, AODA (Ontario) and the UK Equality Act / PSBAR.
- In India, non-compliance can attract scrutiny under the RPwD Act 2016 and departmental audit findings, and can block STQC certification and NIC hosting clearance.
4. Structure of GIGW and WCAG
WCAG is built on the POUR model — Perceivable, Operable, Understandable, Robust — the four principles under which all guidelines and success criteria are grouped. GIGW 3.0 organises requirements into compliance areas that embed WCAG accessibility inside a broader quality/security/governance structure. The tables below present both structures at a glance before the master checklist enumerates every requirement.
4.1 WCAG principles and guidelines
| Principle | Guideline no. | Guideline | Focus |
|---|
| Perceivable | 1.1 | Text Alternatives | Alt text for non-text content |
| Perceivable | 1.2 | Time-based Media | Captions, audio description, transcripts |
| Perceivable | 1.3 | Adaptable | Programmatic structure, meaningful sequence, orientation, input purpose |
| Perceivable | 1.4 | Distinguishable | Colour, contrast, text resize, reflow, spacing |
| Operable | 2.1 | Keyboard Accessible | Full keyboard operability, no traps |
| Operable | 2.2 | Enough Time | Adjustable timing, pause/stop/hide |
| Operable | 2.3 | Seizures and Physical Reactions | Flash thresholds, animation |
| Operable | 2.4 | Navigable | Bypass blocks, titles, focus order, link purpose, headings |
| Operable | 2.5 | Input Modalities | Pointer gestures, target size, motion actuation |
| Understandable | 3.1 | Readable | Language of page/parts, unusual words |
| Understandable | 3.2 | Predictable | On focus/input consistency, consistent navigation |
| Understandable | 3.3 | Input Assistance | Error identification, labels, error prevention |
| Robust | 4.1 | Compatible | Parsing, name/role/value, status messages |
4.2 GIGW 3.0 compliance areas
| GIGW area | Coverage | Relation to WCAG |
|---|
| Website/App Design & Architecture | Layout, navigation, branding, responsiveness, IA | Complements WCAG operability/perceivability |
| Content | Quality, currency, plain language, metadata, multilingual | Supports WCAG understandable |
| Web Quality / Usability | Consistency, broken links, performance, browser compatibility | Complements WCAG robust |
| Accessibility | Direct adoption of WCAG 2.1 Level AA | Is WCAG |
| Technology & Security | Secure coding, HTTPS, STQC security audit, hosting | Beyond WCAG; govt-specific |
| Management & Maintenance | Ownership, review cycle, contingency, archival policy | Governance around all above |
| Mobile Applications | App-specific accessibility, permissions, store hygiene | WCAG applied to native apps |
5. Master Assessment Checklist
This is the core of the audit. Every WCAG guideline (with its Level A, AA and key AAA success criteria) and every GIGW compliance area is enumerated below, each as a group with a table of what the auditor must verify and the typical evidence the implementer should be ready to produce. No control area is skipped. Success criteria are cited by their WCAG identifier and level.
5.1 Guideline 1.1 — Text Alternatives (Perceivable)
| What to verify | Typical evidence |
|---|
| SC 1.1.1 (A) Non-text content: all images, icons, charts, CAPTCHAs and controls have appropriate text alternatives; decorative images are hidden (alt="" / role presentation) | Alt-text inventory, screen-reader (NVDA/JAWS/VoiceOver) recording, HTML source of img/svg/area elements |
5.2 Guideline 1.2 — Time-based Media (Perceivable)
| What to verify | Typical evidence |
|---|
| SC 1.2.1 (A) Audio-only and video-only: transcript or alternative provided | Transcript files, media inventory |
| SC 1.2.2 (A) Captions for prerecorded audio in synchronised media | Caption/VTT files, video review log |
| SC 1.2.3 (A) Audio description or media alternative (prerecorded) | Audio-description track or descriptive transcript |
| SC 1.2.4 (AA) Captions for live audio | Live-caption service configuration, event recordings |
| SC 1.2.5 (AA) Audio description (prerecorded) | Audio-description tracks, production checklist |
5.3 Guideline 1.3 — Adaptable (Perceivable)
| What to verify | Typical evidence |
|---|
| SC 1.3.1 (A) Info and relationships conveyed through structure (headings, lists, tables with th/scope, form labels) are programmatically determinable | Semantic HTML audit, ARIA landmark map, accessibility-tree export |
| SC 1.3.2 (A) Meaningful sequence preserved in DOM/reading order | Linearised reading-order review, tabindex audit |
| SC 1.3.3 (A) Sensory characteristics not the sole cue (not 'click the round button') | Content review notes |
| SC 1.3.4 (AA) Orientation not locked to portrait/landscape | Responsive test on rotated device |
| SC 1.3.5 (AA) Identify input purpose via autocomplete attributes | HTML autocomplete attribute audit of forms |
5.4 Guideline 1.4 — Distinguishable (Perceivable)
| What to verify | Typical evidence |
|---|
| SC 1.4.1 (A) Colour not the only means of conveying information | Design review, colour-blind simulation screenshots |
| SC 1.4.2 (A) Audio control: auto-playing audio >3s can be paused/stopped | Media behaviour test log |
| SC 1.4.3 (AA) Contrast minimum 4.5:1 (3:1 large text) | Contrast-checker report (e.g. axe/Colour Contrast Analyser) |
| SC 1.4.4 (AA) Text resizable to 200% without loss of content | Browser zoom test screenshots |
| SC 1.4.5 (AA) Images of text avoided except where essential | Content/asset audit |
| SC 1.4.10 (AA) Reflow at 320 CSS px width without two-dimensional scroll | Reflow test at 400% zoom |
| SC 1.4.11 (AA) Non-text contrast 3:1 for UI components and graphics | Contrast audit of buttons, focus rings, icons |
| SC 1.4.12 (AA) Text spacing overrides do not clip content | Text-spacing bookmarklet test evidence |
| SC 1.4.13 (AA) Content on hover/focus is dismissable, hoverable, persistent | Tooltip/popover interaction test log |
5.5 Guideline 2.1 — Keyboard Accessible (Operable)
| What to verify | Typical evidence |
|---|
| SC 2.1.1 (A) All functionality operable via keyboard | Keyboard-only walkthrough recording |
| SC 2.1.2 (A) No keyboard trap; focus can move away from any component | Focus-trap test notes |
| SC 2.1.4 (A) Character key shortcuts can be turned off/remapped | Shortcut configuration review |
5.6 Guideline 2.2 — Enough Time (Operable)
| What to verify | Typical evidence |
|---|
| SC 2.2.1 (A) Timing adjustable (extend/turn off/warn) for time limits | Session-timeout config, warning-dialog screenshots |
| SC 2.2.2 (A) Pause, stop, hide for moving/blinking/auto-updating content | Carousel/ticker control test log |
5.7 Guideline 2.3 — Seizures and Physical Reactions (Operable)
| What to verify | Typical evidence |
|---|
| SC 2.3.1 (A) Nothing flashes more than three times per second (or under general/red flash thresholds) | PEAT flash-analysis report, animation inventory |
5.8 Guideline 2.4 — Navigable (Operable)
| What to verify | Typical evidence |
|---|
| SC 2.4.1 (A) Bypass blocks (skip link / landmarks) to repeated content | Skip-link test, landmark map |
| SC 2.4.2 (A) Descriptive, unique page titles | Title-tag inventory across pages |
| SC 2.4.3 (A) Logical focus order | Tab-order walkthrough recording |
| SC 2.4.4 (A) Link purpose clear from link text (in context) | Link-text audit report |
| SC 2.4.5 (AA) Multiple ways to locate pages (search, sitemap, nav) | Sitemap, search feature evidence |
| SC 2.4.6 (AA) Descriptive headings and labels | Heading-outline export |
| SC 2.4.7 (AA) Visible keyboard focus indicator | Focus-visibility screenshots |
5.9 Guideline 2.5 — Input Modalities (Operable)
| What to verify | Typical evidence |
|---|
| SC 2.5.1 (A) Multipoint/path-based gestures have single-pointer alternative | Gesture-alternative test notes |
| SC 2.5.2 (A) Pointer cancellation (down-event does not execute; up-event abortable) | Interaction test log |
| SC 2.5.3 (A) Label in name: visible label text matches accessible name | Accessible-name audit of controls |
| SC 2.5.4 (A) Motion actuation has UI alternative and can be disabled | Motion-trigger test evidence |
5.10 Guideline 3.1 — Readable (Understandable)
| What to verify | Typical evidence |
|---|
| SC 3.1.1 (A) Default human language of page set (lang attribute) | HTML lang attribute audit |
| SC 3.1.2 (AA) Language of parts marked where it changes | Inline lang attribute review |
5.11 Guideline 3.2 — Predictable (Understandable)
| What to verify | Typical evidence |
|---|
| SC 3.2.1 (A) On focus does not trigger unexpected context change | Focus-behaviour test log |
| SC 3.2.2 (A) On input does not auto-trigger unexpected change | Form-interaction test log |
| SC 3.2.3 (AA) Consistent navigation across pages | Cross-page navigation comparison |
| SC 3.2.4 (AA) Consistent identification of components with same function | Component-labelling audit |
5.12 Guideline 3.3 — Input Assistance (Understandable)
| What to verify | Typical evidence |
|---|
| SC 3.3.1 (A) Errors identified and described in text | Form-error screenshots |
| SC 3.3.2 (A) Labels or instructions provided for inputs | Form label/instruction audit |
| SC 3.3.3 (AA) Error suggestion provided where known | Error-message copy review |
| SC 3.3.4 (AA) Error prevention for legal/financial/data submissions (reversible, checked, confirmed) | Confirmation-flow evidence |
5.13 Guideline 4.1 — Compatible (Robust)
| What to verify | Typical evidence |
|---|
| SC 4.1.1 (A) Parsing — well-formed markup (note: obsolete in WCAG 2.2 but tested under 2.0/2.1) | HTML validator report |
| SC 4.1.2 (A) Name, role, value for all custom UI components (ARIA) | ARIA audit, accessibility-tree export |
| SC 4.1.3 (AA) Status messages announced without focus change (aria-live) | Live-region test with screen reader |
5.14 WCAG 2.2 additions (where target level includes 2.2)
| What to verify | Typical evidence |
|---|
| SC 2.4.11 (AA) Focused component not entirely hidden by author content (focus not obscured minimum) | Sticky-header focus test |
| SC 2.5.7 (AA) Dragging movements have single-pointer alternative | Drag-alternative test log |
| SC 2.5.8 (AA) Target size minimum 24x24 CSS px (with exceptions) | Target-size measurement report |
| SC 3.2.6 (A) Consistent help mechanism location | Help-link placement audit |
| SC 3.3.7 (A) Redundant entry avoided across a process | Multi-step form review |
| SC 3.3.8 (AA) Accessible authentication — no cognitive function test without alternative | Auth-flow review (no CAPTCHA-only, no memory-only) |
5.15 GIGW — Design and Architecture
| What to verify | Typical evidence |
|---|
| Consistent global header/footer, National Emblem/branding usage, and standard navigation | Design template, brand-usage screenshots |
| Responsive design across desktop, tablet and mobile | Responsive test matrix |
| Clear information architecture, breadcrumb navigation and homepage link on every page | Sitemap, IA diagram |
| Standard mandatory pages present (About, Contact, Sitemap, Help, Terms, Privacy, Accessibility Statement, Feedback, Hyperlinking policy) | Page inventory checklist |
5.16 GIGW — Content
| What to verify | Typical evidence |
|---|
| Content is accurate, current, authenticated and carries review/update dates | Content review register, page timestamps |
| Plain-language, citizen-centric writing; documents in accessible formats (accessible PDF/HTML) not image-only | Document accessibility audit |
| Metadata, contact of content owner, and multilingual/regional-language support where required | Metadata audit, language-toggle evidence |
| Copyright, hyperlinking, privacy and terms policies published | Policy pages |
5.17 GIGW — Web Quality and Usability
| What to verify | Typical evidence |
|---|
| No broken links, no orphan pages, valid markup and CSS | Link-checker report, W3C validator output |
| Cross-browser and cross-device compatibility | Compatibility test matrix |
| Acceptable page-load performance and optimised assets | Performance/Lighthouse report |
| Search functionality and consistent, error-free user journeys | Search test evidence, usability notes |
5.18 GIGW — Technology and Security
| What to verify | Typical evidence |
|---|
| Site served over HTTPS with valid certificate; secure headers configured | TLS scan, header report |
| STQC / CERT-In empanelled security audit completed and clear before go-live | Security audit certificate, VA/PT report closure |
| Secure coding practices, input validation, protection against OWASP Top 10 | SAST/DAST reports, code-review records |
| Hosting on NIC/authorised infrastructure with backup and DR | Hosting approval, backup/DR policy |
5.19 GIGW — Management and Maintenance
| What to verify | Typical evidence |
|---|
| Named website owner / web information manager and governance responsibilities | RACI, appointment records |
| Defined content review, update and archival/expiry policy | Maintenance policy, archival log |
| Contingency and continuity plan; version control | BCP document, change log |
| Periodic accessibility and quality re-audit schedule | Audit calendar, prior audit reports |
5.20 GIGW — Mobile Applications
| What to verify | Typical evidence |
|---|
| App accessibility (TalkBack/VoiceOver support, focus order, labels, contrast) at WCAG 2.1 AA equivalent | Mobile screen-reader test recordings |
| Minimal, justified permissions and clear privacy disclosure | Permission manifest, privacy policy |
| Store listing hygiene, correct ownership, update mechanism | Store listing evidence |
| Secure API communication and data protection in transit/at rest | Mobile security test report |
6. Scoping
Accurate scoping determines audit effort, sampling strategy and the boundary of the conformance claim. Because WCAG conformance applies to full pages and complete processes (a claim cannot exclude part of a page), scoping must enumerate the pages, templates, dynamic states and end-to-end user journeys in scope.
- Define the target: property (website, web app, mobile app), the conformance target (typically WCAG 2.1 Level AA, with GIGW areas for government), and any AAA aspirations.
- Enumerate page templates and representative unique pages rather than every URL — homepage, landing pages, forms, search results, article/detail pages, transactional flows, error states, authenticated dashboards.
- Include complete processes end to end (e.g. registration, application submission, payment) — WCAG requires every page in a process to conform for the process to conform.
- Capture all key states and components: modals, menus, carousels, data tables, date pickers, file uploads, CAPTCHAs, PDFs and other downloadable documents.
- List assistive-technology and browser combinations to test (NVDA+Firefox, JAWS+Chrome, VoiceOver+Safari, TalkBack+Chrome on Android).
- Note out-of-scope items explicitly (third-party embedded content, legacy archived pages) and their justification, since these affect the conformance claim.
- For GIGW, additionally scope security audit boundary, hosting environment and content governance processes.
7. Implementation Approach
A phased approach moves an organisation from unknown accessibility posture to sustained conformance. Each phase below lists core activities and deliverables. 'Shift left' — embedding accessibility into design and development — is far cheaper than late remediation.
7.1 Phase 1 — Discovery and Baseline
- Activities: define scope and target level; run automated scans (axe, WAVE, Lighthouse, ARC); commission a baseline manual audit on a sample; inventory pages, templates and documents.
- Deliverables: scope document, baseline conformance report, prioritised defect backlog, GIGW gap register.
7.2 Phase 2 — Planning and Governance
- Activities: appoint accountable owner; set target date and level; define accessibility policy and design standards; select tooling; plan training.
- Deliverables: accessibility policy, remediation roadmap with priorities and owners, design-system accessibility guidelines, training plan.
7.3 Phase 3 — Design and Build Remediation
- Activities: fix defects by severity (blockers first — keyboard traps, missing labels, contrast); embed accessible components in the design system; add ARIA correctly; author accessible documents.
- Deliverables: remediated components, accessible pattern library, updated code with unit/integration accessibility checks in CI.
7.4 Phase 4 — Verification and Testing
- Activities: combine automated, manual and assistive-technology testing; usability testing with Persons with Disabilities; verify complete processes; for GIGW run security and quality audits.
- Deliverables: verification report, screen-reader test evidence, security clearance, corrected-issue log.
7.5 Phase 5 — Conformance Claim and Certification
- Activities: prepare Accessibility Conformance Report (VPAT/ACR); publish Accessibility Statement; apply for STQC GIGW certification; obtain sign-off.
- Deliverables: signed conformance claim, published accessibility statement, STQC certificate (where applicable).
7.6 Phase 6 — Sustain and Monitor
- Activities: integrate accessibility gates into CI/CD; schedule periodic re-audits; monitor feedback channel; retrain teams; re-test after major releases.
- Deliverables: monitoring dashboard, re-audit schedule, updated backlog, feedback-resolution log.
WCAG itself is pass/fail per success criterion at a chosen level (a page either conforms or it does not), but organisations track a maturity/capability view to plan improvement. The table below presents a five-level maturity model plus the formal WCAG conformance levels.
| Maturity level | Description | Typical state |
|---|
| Level 0 — Absent | No awareness or policy; accessibility not considered | Numerous Level A failures, keyboard traps |
| Level 1 — Initial / Reactive | Ad hoc fixes after complaints; automated scans only | Partial Level A; no manual testing |
| Level 2 — Managed | Policy exists; manual audits on key pages; defined target level | Approaching Level AA on core pages |
| Level 3 — Defined | Accessibility in design system and CI; training in place | Level AA across most templates |
| Level 4 — Measured | Metrics tracked; PwD usability testing; regular re-audit | Sustained AA; some AAA |
| Level 5 — Optimising | Accessibility-by-default culture; continuous improvement | Robust AA/AAA, low defect recurrence |
| WCAG conformance level | Requirement | Typical use |
|---|
| Level A | All Level A success criteria met | Absolute minimum; insufficient alone |
| Level AA | All A and AA success criteria met | Legal/procurement baseline; GIGW target |
| Level AAA | All A, AA and AAA met (not required for whole sites) | Enhanced accessibility for specific content |
9. Assessment and Audit Approach
A defensible audit blends automated coverage (fast, but detects only a minority of issues) with expert manual testing and assistive-technology validation. The recommended process follows WCAG-EM (Website Accessibility Conformance Evaluation Methodology).
- Define the evaluation scope, conformance target (e.g. WCAG 2.1 AA) and any GIGW areas.
- Explore the target: identify page types, key functionality, technologies, states and complete processes.
- Select a representative sample: structured sample of common pages plus a random sample, ensuring full processes are covered.
- Run automated testing across the sample to surface machine-detectable issues and coverage breadth.
- Perform manual expert testing: keyboard-only operation, semantics/ARIA review, contrast, reflow, zoom, and content checks.
- Perform assistive-technology testing with NVDA, JAWS, VoiceOver and TalkBack across the browser matrix.
- Conduct functional/usability testing of complete processes, ideally involving Persons with Disabilities.
- Record each failure against its specific success criterion with severity, location, reproduction steps and remediation guidance.
- For GIGW, execute security (STQC/CERT-In) and quality/link/performance checks and content-governance review.
- Aggregate results, determine conformance level achieved, and produce the report and conformance claim (ACR/VPAT).
- Support remediation, then re-test fixed items and issue the final signed conformance statement.
10. Evidence Request List
The following evidence, grouped by category, should be requested from the implementer/product team ahead of and during the audit.
- Governance: accessibility policy, appointed owner/RACI, GIGW compliance ownership records, roadmap.
- Design: design system/pattern library accessibility guidance, colour palette with contrast values, wireframes.
- Code and markup: source of representative templates, ARIA usage documentation, autocomplete/label conventions.
- Testing artefacts: automated scan reports (axe/WAVE/Lighthouse), manual audit reports, screen-reader test recordings, keyboard walkthrough videos.
- Media and documents: caption/transcript files, audio-description tracks, accessible PDF/office documents.
- Conformance: prior Accessibility Conformance Report / VPAT, Accessibility Statement, feedback-channel logs.
- Security and quality (GIGW): STQC/CERT-In security audit report and clearance, TLS/header scans, link-check and performance reports, hosting/DR approvals.
- Process evidence: complete-process test recordings (registration, payment), error-handling screenshots, session-timeout configuration.
- Mobile (if applicable): TalkBack/VoiceOver test recordings, permission manifest, store listing, mobile security report.
11. Roles and Responsibilities
| Role | Responsibility |
|---|
| Website/App Owner (Web Information Manager) | Accountable for GIGW/WCAG compliance, sign-off and governance |
| Accessibility Lead / Champion | Owns policy, standards, training and remediation roadmap |
| UX / Visual Designer | Delivers accessible designs — contrast, focus, layout, target sizes |
| Front-end Developer | Implements semantic HTML, correct ARIA, keyboard support |
| Content Author / Editor | Provides alt text, headings, plain language, accessible documents |
| QA / Accessibility Tester | Runs automated, manual and AT testing; logs defects to SC |
| Security Auditor (STQC/CERT-In) | Conducts GIGW security audit and issues clearance |
| External Auditor / Assessor | Independent conformance evaluation and ACR issuance |
| Persons with Disabilities (test participants) | Provide real-world usability validation |
12. KPIs to Track
- Conformance level achieved per template (A / AA / AAA) and percentage of pages at target level.
- Number of open accessibility defects by severity (blocker, critical, major, minor) and mean time to remediate.
- Automated scan pass rate and trend over time.
- Percentage of design-system components that are accessibility-certified.
- Number of complete user processes fully conformant end to end.
- Screen-reader task success rate in usability testing with Persons with Disabilities.
- Accessibility defects escaping to production per release (defect leakage).
- Percentage of new content published with alt text and accessible documents on first publish.
- Time to acknowledge and resolve accessibility feedback from the public channel.
- GIGW/STQC certification status and security-audit clearance currency.
13. Readiness Checklist
- Conformance target defined (e.g. WCAG 2.1 AA) and GIGW areas identified
- Scope document lists templates, states and complete processes
- All non-text content has appropriate text alternatives
- Full keyboard operability with visible focus and no traps
- Colour contrast meets 4.5:1 (text) and 3:1 (UI/large text)
- Content reflows at 320px and text resizes to 200% without loss
- All form fields have labels, instructions and clear error handling
- Semantic structure, headings, landmarks and ARIA name/role/value correct
- Captions, transcripts and audio descriptions provided for media
- Downloadable documents (PDF/office) are accessible
- Accessibility Statement and feedback channel published
- Automated, manual and assistive-technology testing completed on the sample
- Mandatory GIGW pages and policies present
- STQC/CERT-In security audit cleared (for government properties)
- Accessibility Conformance Report / VPAT prepared and signed off
- Re-audit schedule and CI/CD accessibility gates in place
14. Common Gaps
- Relying on automated scans alone — they detect only around a third of issues, missing keyboard, screen-reader and cognitive problems.
- Missing or meaningless alt text, and decorative images not hidden from assistive technology.
- Insufficient colour contrast and no visible keyboard focus indicator.
- Custom widgets (dropdowns, modals, tabs) built without correct ARIA name/role/value, breaking with screen readers.
- Keyboard traps in modals, carousels and embedded media.
- Form fields without programmatic labels and errors conveyed by colour only.
- Image-only or untagged PDFs treated as accessible content.
- CAPTCHAs and authentication that impose cognitive/memory tests with no accessible alternative (SC 3.3.8).
- Content that reflows poorly or locks orientation on mobile.
- Auto-playing media, moving carousels and time limits with no pause/stop/extend controls.
- Treating accessibility as a one-off audit rather than a sustained, CI-integrated practice.
- For GIGW: missing mandatory pages, outdated content, and go-live before security-audit clearance.
15. GIGW / WCAG Mapped to Other Frameworks
| Framework / regulation | Region | Relationship to WCAG/GIGW |
|---|
| EN 301 549 | EU | Adopts WCAG AA for ICT accessibility procurement |
| Section 508 | USA | Incorporates WCAG 2.0 AA for federal ICT |
| ADA (Title II/III) | USA | Courts apply WCAG AA as the practical standard |
| European Accessibility Act | EU | Mandates accessibility, aligned to WCAG/EN 301 549 |
| AODA | Canada (Ontario) | Requires WCAG AA for public websites |
| UK Equality Act / PSBAR | UK | Public bodies must meet WCAG AA |
| RPwD Act 2016 & Rules | India | Mandates accessible ICT; references GIGW/WCAG |
| ISO/IEC 40500 | Global | Is WCAG 2.0 published as an ISO standard |
| STQC certification scheme | India | Certifies GIGW compliance including WCAG AA accessibility |
| EN 301 549 mobile clauses | EU/Global | Extends WCAG principles to native mobile apps (as GIGW does) |
16. How CyberSigma Helps
Partner with CyberSigma for GIGW & WCAG Assurance
CyberSigma brings CERT-In empanelled and QSA-grade rigour to accessibility and government web assurance. We deliver end-to-end GIGW & WCAG 2.1/2.2 AA engagements: baseline audits combining automated, expert-manual and assistive-technology testing (NVDA, JAWS, VoiceOver, TalkBack); WCAG-EM sampled evaluations of complete user journeys; remediation guidance mapped to each success criterion; accessible design-system and component uplift; document remediation; STQC/CERT-In security-audit coordination; and preparation of your Accessibility Conformance Report, Accessibility Statement and GIGW certification pack. We also embed accessibility gates into your CI/CD and train your design, development and content teams so conformance is sustained, not one-off. Talk to CyberSigma to make your citizen and customer digital services accessible, compliant and audit-ready.
