The hidden cost of vibe coding:Why accessibility
can’t be an afterthought

Something fundamental shifted in software development in 2023 — and by 2025 it has become the dominant story in how organizations build digital products. AI app builders, copilots, and “vibe coding” platforms have collapsed the traditional barrier between idea and execution. A product manager can now describe a CRM dashboard in plain language and have a functional prototype in under an hour. A startup founder with no engineering background can ship a customer-facing web application in a weekend.

The term “vibe coding” — coined by AI researcher Andrej Karpathy in February 2025 as a shorthand for the practice of prompting AI models to generate, iterate, and deploy code with minimal traditional programming knowledge — moved from social media into boardroom vocabulary with remarkable speed. Platforms like Bolt.new, Lovable, v0 by Vercel, Cursor, GitHub Copilot, and an entire ecosystem of specialist AI builders have made this a mainstream methodology, not an experimental curiosity.

The efficiency numbers are real. McKinsey research suggests AI coding assistance can reduce development time for new features by 20–45% in controlled studies (McKinsey Technology Trends, 2023) — the range is wide and depends on task type and developer experience. For greenfield projects — building from scratch — the gains can be even more dramatic. The business case for AI-assisted development is no longer theoretical; it is being demonstrated in production every day across every industry.

To understand why accessibility is so systematically overlooked in AI-generated code, you need to understand how these tools are trained and optimised. Large language models learn from the vast corpus of existing code on the internet. And existing code on the internet has a well-documented accessibility problem: WebAIM’s annual Million report consistently finds that over 95% of homepage content fails at least one WCAG 2.1 AA criterion. The training data is, in aggregate, inaccessible.

When you ask an AI builder to “create a navigation menu” or “build a modal dialog” or “add a form with validation”, the model draws on patterns from that corpus. Without explicit instruction — and sometimes even with it — it produces code that reflects the median of its training data. Images without alt text. Form inputs without associated labels. Custom interactive elements that cannot be keyboard-navigated. Focus states stripped out for aesthetic reasons. Colour contrasts that fail at 3.2:1 when the minimum is 4.5:1.

This is not a minor edge case. It is the default behaviour.

The economics of AI development are compelling on the surface. A project that might have cost €200,000 in traditional development resources can be prototyped for a fraction of that. But this calculation routinely omits a critical variable: the cost of accessibility remediation.

The widely-cited figure from IBM’s research — that fixing a defect found during production is 100× more expensive than preventing it during design — is borne out in accessibility specifically. Retrofitting accessibility into an existing codebase is not a matter of adding a few attributes. It often requires rearchitecting components, rewriting interaction patterns, updating design systems, re-testing across assistive technologies, and training teams who have never considered these dimensions before.

Consider a mid-size enterprise that uses AI tooling to build a customer portal in 8 weeks instead of 24. The initial savings are substantial — perhaps €150,000 in developer time alone. But if the portal fails a mandatory accessibility audit (required for EU public-sector or financial services applications under the European Accessibility Act), the cost to remediate can easily reach €80,000–€180,000 when you factor in design rework, engineering, re-testing, and delayed go-live.

The net saving evaporates. And that is before considering legal exposure.

The legal landscape around digital accessibility is tightening rapidly, and organizations that treat it as optional are taking on significant and growing liability. This is not a theoretical future risk — it is a present operational one.

The European Accessibility Act (EAA), which took full effect for private-sector products and services in June 2025, extends the scope of mandatory accessibility compliance dramatically. Banks, e-commerce platforms, telecom services, transport booking systems, e-books, and consumer electronics software must all meet WCAG 2.1 AA requirements or face enforcement action, including fines and market withdrawal orders.

In the United States, ADA Title III litigation targeting web properties has increased by over 300% since 2018, with no sign of abating. The average settlement cost in a web accessibility lawsuit is now estimated between $25,000 and $100,000 — before considering the cost of subsequent mandatory remediation and monitoring.

WCAG 2.2, published in October 2023, builds on WCAG 2.1 with three new success criteria at Level AA (and one at Level A) that directly address patterns common in modern web applications — including those built with AI tools. Understanding what has changed and what remains is essential for teams building in 2025.

The standard is organised around four principles — Perceivable, Operable, Understandable, and Robust (POUR) — and each criterion is either Level A (essential), Level AA (the legal standard), or Level AAA (enhanced). AI-generated interfaces typically struggle across all four principles simultaneously.

The good news is that integrating accessibility into AI-assisted development does not require abandoning the productivity benefits that make vibe coding attractive in the first place. It requires a deliberate architectural shift in how you deploy AI tools, not whether you use them. The following framework reflects AIOPSGROUP’s proven methodology for clients building with AI at scale.

Not all AI development tools are equal in their accessibility output. While none currently generates WCAG 2.2 AA compliant code by default, there are meaningful differences in how they respond to accessibility-focused prompting, what components they include in their default outputs, and what escape hatches they provide for manual correction. The following assessment is based on AIOPSGROUP evaluation as of Q1 2025.

The vibe coding revolution is real, and the efficiency gains are real. We are not arguing against AI app builders — quite the opposite. We use them ourselves and help clients deploy them at scale. But the uncritical adoption of these tools, without accounting for their systematic accessibility blind spots, is creating a wave of technical and accessibility debt that will cost far more to address than the original efficiency gains were worth.

The good news is that this is entirely preventable. Accessibility is not at odds with speed — it is a constraint that, when baked into your AI prompting strategy, component library, and CI/CD pipeline, adds days to a project, not weeks. The cost of prevention is measured in hours. The cost of remediation is measured in sprints, legal fees, and customer exclusion.

Think of accessibility the way forward-thinking engineering teams now think about security: not a compliance check at the end of the process, but a design principle embedded in every layer of how you build. Just as “shift left on security” became standard practice in the DevSecOps movement, the imperative now is to shift left on accessibility — and AI development teams have more leverage to do this than any previous generation of builders.

At AIOPSGROUP, a valantic company, we help organizations navigate exactly this challenge — from accessibility audits and WCAG conformance programmes, to AI prompt engineering frameworks, training, and ongoing managed compliance. If your team is building with AI and accessibility is not yet part of your workflow, this is the right moment to change that.