Building Accessible Government Services: WCAG 2.2 + GIGW Combined
Accessibility for government services isn't a checkbox, it's the difference between including or excluding millions of Indians with disabilities. Here's how to build to WCAG 2.2 AA + GIGW 3.0 together.
Key takeaways
- WCAG 2.2 added new criteria around touch targets, focus appearance, and consistent help. GIGW 3.0 layers on India-specific.
- Build with screen-reader testing from day one, not at the end.
- Vernacular accessibility means more than translation, voice input, larger touch targets, simpler flows.
- Test with real users with disabilities. Tools are necessary but not sufficient.
Why this matters
India has approximately 27 million people with disabilities per recent census; many more report functional impairments. A government service that's inaccessible excludes them. Beyond ethics, it's a compliance gate.
What WCAG 2.2 added
Key new criteria for AA:
- Focus appearance: focus must be clearly visible, with sufficient contrast.
- Dragging movements: any drag operation must have a non-drag alternative.
- Target size: interactive targets minimum 24x24 px (smaller allowed only if inline in text).
- Consistent help: help options consistent across the site.
- Redundant entry: don't ask for the same info twice.
- Accessible authentication: don't rely on cognitive memory tests.
What GIGW 3.0 adds for India
- Vernacular support (Hindi, English, regional)
- Right-to-left language support
- India-specific date/number/currency formats
- Government identity placement
- Document accessibility (PDFs, Word, Excel)
Patterns that work
Semantic HTML first
<button> for buttons, <a> for links, headings in proper hierarchy. Screen readers depend on semantic structure.
Keyboard navigation
Every interactive element reachable and operable by keyboard alone. Visible focus state. Logical tab order. Skip-to-content link.
Form accessibility
Every input has a <label>. Errors are programmatically associated. Required fields marked. Instructions before the input, not after.
Color and contrast
Never rely on color alone. Contrast 4.5:1 for normal text, 3:1 for large.
Touch targets
24×24 px minimum. 44×44 ideal on touch devices.
Vernacular voice input
Many users with disabilities prefer voice. Support it on input fields where possible.
Live regions for dynamic updates
When content changes (form errors, status updates), use aria-live regions so screen reader users hear it.
Testing
Automated
axe-core or Lighthouse in CI. Catches roughly 40% of issues.
Manual screen reader
NVDA on Windows, VoiceOver on Mac/iOS, TalkBack on Android. Walk the user flow.
Keyboard-only
Tab through the entire app. Every interactive element reachable, every action completable.
Real users
Recruit users with disabilities for actual usability testing. Tools miss what humans catch.
Common pitfalls
Tooltip-only labels. Screen readers don't always announce. Use visible labels.
Custom widgets. Custom dropdowns, sliders, modals often break accessibility. Use semantic HTML or rigorously test ARIA implementation.
Skip links hidden. Skip-to-content link present but display:none. Make it visible on focus.
PDFs untagged. Untagged PDFs are inaccessible. Tag them.
What we recommend
Hire or train at least one team member as accessibility owner. Make accessibility a release gate. Test with real users with disabilities quarterly.
FAQs
WCAG 2.2 vs 2.1? 2.2 is newer; some criteria are stricter. GIGW 3.0 references 2.1; compliance with 2.2 covers both.
Cost of accessibility? 5-15% of project cost if built in. 30-50% if retrofitted.
Indian regulations beyond GIGW? Rights of Persons with Disabilities Act applies to all public services.