
If you are building or maintaining an Indian government website, portal, or app, accessibility cannot be reduced to a Lighthouse score.
GIGW 3.0 accessibility testing needs a mix of automated checks, manual review, assistive technology checks, document review, and evidence that remediation teams can act on.
1. Build the scope list first
Before testing, list the real assets.
- Public pages.
- Login and authenticated areas.
- Search and filter pages.
- Forms and validation states.
- Upload, download, and payment flows.
- Mobile app screens.
- PDFs and scanned documents.
- Videos and audio.
- Grievance and contact workflows.
This prevents the common problem where only the public homepage is tested.
2. Use automated checks as the first pass
Automated tools are useful for common failures:
- Missing accessible names.
- Some colour contrast issues.
- Duplicate IDs.
- Obvious ARIA problems.
- Missing document language.
- Empty headings or buttons.
But they are not enough. They cannot prove task completion.
3. Manually test keyboard behavior
Keyboard testing should include:
- Tab sequence.
- Shift+Tab sequence.
- Enter and Space activation.
- Escape behavior in dialogs.
- Focus trapping where appropriate.
- No accidental keyboard traps.
- Visible focus on every interactive element.
Custom controls need extra attention because native behavior is often lost when teams recreate UI components.
4. Test forms with real errors
Forms need more than labels.
Check:
- Required field indication.
- Label association.
- Help text association.
- Error message association.
- Summary and inline error behavior.
- State changes after submission.
- Timeout and session handling.
- OTP, CAPTCHA, and verification alternatives.
Use realistic data so validation states appear.
5. Review documents separately
PDF and document accessibility needs its own pass.
Check tags, reading order, headings, table structure, link text, alt text, document language, title metadata, and form fields. If a file is scanned, OCR alone is not enough. The document still needs semantic structure.
6. Test mobile and app behavior
For responsive pages and apps, test with platform accessibility settings.
- Screen reader order.
- Text scaling.
- Display scaling.
- Orientation changes.
- Touch target spacing.
- Gesture alternatives.
- Control name, role, state, and value.
Government app flows often fail here because desktop assumptions do not transfer cleanly to mobile.
7. Write findings developers can close
A useful issue includes:
- Location.
- Steps to reproduce.
- Expected behavior.
- Actual behavior.
- User impact.
- WCAG or GIGW mapping.
- Severity.
- Fix guidance.
- Retest note.
If a developer cannot reproduce the issue, the report is not ready.
Conclusion
GIGW 3.0 accessibility testing should be practical, not ceremonial.
Start with scope, combine automated and manual testing, include documents and apps, write actionable findings, and retest fixes with evidence.
Read the original guide on IAAP Audit: https://iaapaudit.com/blog/gigw-3-0-accessibility-checklist-websites-apps
Top comments (0)