A senior engineer ships a checkout flow in an afternoon. The AI assistant handles the heavy lifting, the happy path works, and everything looks fine visually. Two weeks later, customer support forwards a complaint: a blind user cannot complete the purchase because the “Pay Now” control is a <div> with a click handler, no ARIA role, and no keyboard focus. The order cannot be placed.
That gap between code that runs and a product people can actually use is, according to software engineer Mikhail Prosmitskiy writing for Smashing Magazine, one of the defining engineering challenges of the current AI development era. His argument is direct: accessibility belongs in the same category as security, privacy, reliability, and observability. It is not a feature to ship once, and it is not a box to check at the end of a project.
The Limits of the Audit Model
Accessibility audits have a legitimate place. Procurement conversations, legal documentation, VPATs, and ACRs all require them. But audits have a structural problem: they are snapshots. Six months after a firm delivers its 200-item findings report, the product has shipped dozens of releases, new features, and a redesigned navigation. The report describes a product that no longer exists.
The WebAIM Million report, which scans the top one million home pages annually, found that 95.9 percent of pages had detectable WCAG failures in its 2026 run, with an average of 56.1 errors per page. The number of page elements jumped more than 20 percent in a single year, a trend the report attributes in part to AI-assisted development. More elements mean more places to break.
Accessibility debt compounds exactly like technical debt. Every inaccessible component shipped becomes a future remediation project, and the interest accumulates with every release.
AI-Generated UI Is Inaccessible by Default
The term “vibe coding,” coined by Andrej Karpathy in February 2025, describes a workflow where a developer describes intent, accepts AI-generated diffs without close review, and moves on. Y Combinator reported that 25 percent of its Winter 2025 batch had codebases that were 95 percent AI-generated. That pace of generation makes the accessibility problem significantly worse.
Three forces push language models toward non-semantic markup. First, most React code in training data uses non-semantic patterns, so models reproduce them. Second, human reviewers evaluate output visually, so the feedback loop rewards appearance over structure. Third, <div onClick> is simply fewer tokens than a properly attributed <button> element, so absent an explicit constraint, models take the shorter path.
Testing documented in the article found a typical AI-generated sidebar component with ten distinct accessibility failures in under thirty lines of code: no landmark, no heading hierarchy, no list structure, click handlers on non-interactive elements, missing ARIA attributes, no keyboard handling, and unlabeled icons. The resulting accessibility tree was flat, unstructured text. As the author puts it, the visual and the accessible versions look the same on screen, but one is a door and the other is a painting of a door.
The Shared Root with Security Failures
Prosmitskiy draws a direct connection between accessibility failures and security failures in AI-generated code. Veracode’s 2025 GenAI Code Security Report found that a significant fraction of AI-generated code introduced security vulnerabilities, including OWASP Top 10 issues, with cross-site scripting failures particularly common. Security performance did not improve meaningfully with newer or larger models.
The root cause in both cases was process: developers generating code without specifying constraints and accepting output without systematic verification. The same shortcut that bypasses a security review bypasses an accessibility review.
What This Means for WordPress and Web Teams
For site owners and development teams working in WordPress, the practical implications are straightforward:
- Automated accessibility checks belong in CI/CD pipelines, not in quarterly audits. Catching a missing button role before merge is far cheaper than a customer support escalation after deployment.
- AI-generated components need explicit accessibility constraints in prompts and systematic review before acceptance. Assuming the output is correct is not a process.
- Compliance is not a state you reach. It is a state you maintain across every release, and the complexity of modern page structure works against you continuously.
The article frames this not as a legal or ethical argument, though both apply, but as an engineering systems problem. Teams that treat accessibility as a continuous property of the system, monitored and enforced at each stage of development, are the ones that will not find themselves answering for a broken checkout flow two weeks after launch.