What GIGW Actually Requires
WCAG 2.1 AA compliance is the baseline. This means semantic HTML, colour contrast ratios (4.5:1 for normal text), keyboard navigation for every interactive element, screen reader compatibility, text alternatives for all non-text content, and no content that flashes more than three times per second.
Beyond accessibility: the site must work without JavaScript enabled (graceful degradation), support screen sizes from 320px to 2560px, have meaningful page titles and meta descriptions, load within 3 seconds on a 2G connection, and be navigable without a pointing device.
Where It Gets Hard
The 'works without JavaScript' requirement conflicted with about forty percent of my component library. Modal dialogs, dropdown menus, tab interfaces — all of these need JavaScript to be accessible. The GIGW requirement means you need a functional, accessible fallback for every JS-dependent component.
Colour contrast was harder than expected. The design used subtle, low-contrast text for secondary information — common in modern dark-themed UIs. Every one of those needed to be audited against the WCAG ratio formula and adjusted. Some design decisions had to change fundamentally to meet the standard.
Key takeaways
- WCAG 2.1 AA and GIGW share most requirements — implementing one rigorously gets you most of the way to the other
- Test with a real screen reader (NVDA on Windows, VoiceOver on Mac) — automated accessibility testing catches maybe 30% of actual issues
- The no-JS fallback requirement is the most disruptive for modern SPA architecture — plan for it in your component design, not as an afterthought
Conclusion
GIGW compliance is hard, expensive, and occasionally forces you to simplify designs that weren't serving users anyway. The resulting applications are more accessible, more robust, and work for a wider range of users and devices. It's worth doing properly.
Enjoyed this article?
Vivek Kumar Singh
Technical Expert · Full Stack Cloud Engineer · Tokyo, Japan
