Google recently announced what they called “Modern Web Guidance” (MWG) at Google I/O, pitching it as an expert-vetted framework to help AI coding agents build accessible, secure, and performant web experiences. And how great it would be if it worked.
To show off MWG they used Antigravity, a prototype AI coding tool designed to turn natural language prompts into clean, accessible code.
The promise sounds great: feed a prompt to AI, and out pops a perfectly optimized, fully accessible component, ready to be published as-is.
As it stands now, Antigravity has the same problems any LLM has, since these problems seem to be inherent to the technology:
- It lies well
- It doesn’t follow the rules
- It spits out too much code to be reliably audited
With the tech where it is, you simply can’t trust AI to get it right all the time. MWG itself is a solid set of rules, but if Antigravity – which is allegedly expressly built to make accessible code – doesn’t follow it, then it’s no better than any other AI coding platform.
It’s just another hype tool that works for builders but not for users, and I’m honestly kind of frustrated by it.
Accessibility issues in Google’s showcase example
When you audit AI-generated code (and you really should be auditing AI-generated code), you’re likely to find recurring failures to implement basic WCAG requirements. You’re probably evaluating or already using AI coding tools right now, drawn by promises of faster development cycles and democratized coding.
But if AI can’t handle the accessibility requirements that affect more than 2.5 billion people worldwide, the promised productivity gains become technical debt that costs significantly more to remediate than just… building things the right way from the start.
The Roselli Report (not the official title)
Accessibility expert Adrian Roselli put Antigravity and MWG to the test using Google’s own launch prompt: creating an animating, accordion-style stats component. The AI’s output looked great on the surface. Smooth animations, custom themes, some configuration settings. Everything we could want, right?
Roselli identified several critical failures in the code generated by Antigravity, including:
- Functionality: The core animation failed completely in Firefox, violating basic cross-browser reliability.
- Accessibility: Despite MWG’s explicit focus on accessibility, the component failed basic WCAG compliance in a number of areas. See the above hyperlinked article for a more complete explanation of what was found.
- Inefficiency: The AI injected redundant, non-DRY (Don’t Repeat Yourself) code and unnecessary dependencies like unwanted Google fonts.
My concurring opinion
With the tech where it is now (at time of writing this article in June 2026), you can’t trust an LLM to build reliable interfaces, even when it’s fed “vetted” guidance.
AI models are non-deterministic. They routinely ignore instructions, misunderstand rules, or generate wildly different errors each time you run a prompt. Relying on them forces developers to spend extra time hunting down subtle, unpredictable bugs.
It’s still the fastest and most reliable solution, most of the time, to maintain a well-vetted, hand-coded internal pattern library that delivers identical, reliable results every time.
Which raises a bigger question about how we build for the web. AI tools are great, don’t get me wrong. You just need a knowledgeable team to go through and check the output after AI does its thing, because it sure is good at lying and ignoring.
Google had all the right documentation and still got it wrong
Google explicitly documented their AI training methodology, claiming to have incorporated W3C accessibility guidelines, WCAG compliance documentation, and modern web development best practices. The system had direct access to authoritative accessibility resources during training, including examples of proper ARIA implementation patterns.
But when tasked with generating an accordion component, the AI ignored every established pattern in the W3C ARIA Authoring Practices Guide. The official APG provides explicit code examples for accordion implementation (`role=”button”` on headers, `aria-expanded` attributes that toggle between “true” and “false,” and proper focus management with `aria-controls` linking headers to panels, to name a few).
These patterns are documented with working code samples, detailed explanations, and browser compatibility notes. Google’s AI had access to this exact documentation during training, and still the generated code violated every single requirement.
The pattern matching issue becomes more troubling when examined against specific training claims. Google claimed their AI learned from accessibility-compliant code examples and comprehensive WCAG documentation. But accessibility compliance requires understanding the relationship between semantic HTML, ARIA attributes, and assistive technology behavior. The AI treated accessibility attributes as optional decorations rather than functional requirements. It generated `div` elements instead of proper button semantics, omitted state management entirely, and created visual interactions that work only with mouse input.
Across the board, it was a deprioritization of accessibility requirements in favor of visual presentation.
The cost of AI-generated accessibility issues
Most enterprise development teams now use AI coding assistants in production environments, and yet few have established validation processes for accessibility compliance in AI-generated code. Teams are discovering accessibility failures after deployment because their existing QA workflows weren’t designed to catch the problems that AI code generation produces. If you treat AI-generated components like manually-written code in your review process, you’ll miss the recurring accessibility failures that require different evaluation approaches.
Federal agencies and contractors face acute risk under Section 508 requirements, where accessibility compliance is legally mandated for all digital services. Private sector organizations operating in regulated industries or serving government contracts face similar exposure under ADA Title II and state accessibility laws.
Accessibility violation settlements can reach hundreds of thousands of dollars per incident, with remediation expenses often exceeding the original settlement. Organizations deploying AI-generated code without accessibility validation are conducting live user testing with legal liability attached.
Automated accessibility testing tools are great, but they’re also designed to catch missing alt text and color contrast violations, not the structural problems that AI systems commonly produce. Tools like axe-core and WAVE can identify explicit WCAG violations but can’t evaluate whether an accordion component properly manages focus states or announces state changes to screen readers.
Manual testing with actual screen readers becomes essential for validating AI-generated interactive components. Here’s a crash course in how to make that happen if you aren’t familiar:
Responsible building with AI
At this point it probably sounds like Silktide is against using AI to build things. Not quite – but we are against using it willy-nilly (or as my mom would say, William Nilliam). Please, please, please know what you’re doing; build with tools that are prepared by actual accessibility experts; and then audit it afterward, ideally manually.
For better and for worse, AI will affect digital accessibility. Evaluating these systems for bias and exclusion improves inclusivity outcomes, but most development teams deploy AI-generated code without this validation step. The promise of democratizing development through AI becomes a cruel irony when the resulting websites continue to exclude users with disabilities. Organizations celebrate reduced development costs while externalizing the real expense onto users who have to navigate broken interfaces or seek alternative service channels. The burden shifts from developers to the users that accessibility standards were designed to protect.
It’s on all of us, as the builders, to make things better for everyone.
References
- Akiba, D., Pagliara, S., Truss, M., Nwokoye, C., & Waters, G. (n.d.). AI testing, evaluation, verification and validation for accessibility: a comprehensive framework. Front. Digit. Health, 7, 1679603. https://doi.org/10.3389/fdgth.2025.1679603
- Browser Compatibility tables and Browser Compatibility Data (BCD) – MDN Web Docs | MDN. (2025, September 19). Mozilla.org. https://developer.mozilla.org/en-US/docs/MDN/Writing_guidelines/Page_structures/Compatibility_tables
- Digital Accessibility, & Zennermann, E. (2024, April 18). Key Takeaways from WebAIM’s Screen Reader User Survey #10 – Digital Accessibility. Digital Accessibility. https://www.rochester.edu/digital-accessibility/key-takeaways-from-webaims-screen-reader-user-survey-10/
- Initiative (WAI), W. W. A. (n.d.). ARIA Authoring Practices Guide. Web Accessibility Initiative (WAI). https://www.w3.org/WAI/ARIA/apg/
- Kerner, S. M. (2025, July 29). Stack Overflow data reveals the hidden productivity tax of “almost right” AI code. Venturebeat; VentureBeat. https://venturebeat.com/ai/stack-overflow-data-reveals-the-hidden-productivity-tax-of-almost-right-ai-code
- New flexbox guides on MDN – Mozilla Hacks – the Web developer blog. (2018). Mozilla Hacks – the Web Developer Blog. https://hacks.mozilla.org/2018/01/new-flexbox-guides-on-mdn/
- Taylor, J. (2026, January 8). ADA Web Lawsuit Trends for 2026: What 2025 Filings Reveal. Usablenet.com; UsableNet Inc. https://blog.usablenet.com/ada-web-lawsuit-trends-2026
- U.S. Access Board – General Services Administration Publishes Annual Governmentwide Section 508 Assessment. (2026). Access-Board.gov. https://www.access-board.gov/news/2026/03/05/general-services-administration-publishes-annual-governmentwide-section-508-assessment/
- w3c_wai. (2019). [Archived] WCAG 2.1 Implementation List. W3.org. https://www.w3.org/WAI/WCAG21/implementation-report/implementation%3Fimplementation_id=130.html
- Web Browser Accessibility Features | NCRTM. (2026). Ed.gov. http://ncrtm.ed.gov/browser-accessibility
