Why Accessibility Is An Operational Capability, Not A Feature — Smashing Magazine

When a Blind Customer Can’t Check Out

A senior engineer ships a checkout flow in a single afternoon. An AI assistant does the heavy lifting, the happy path runs clean, and a rotating chevron spins on the order summary. Two weeks later, customer support gets a notice: a blind shopper using a screen reader can’t complete the purchase because “Pay Now” is a <div> with a click handler. No role. Not focusable. Not working.

That gap — between code that runs and a product people can actually use — is one of the defining engineering challenges of the AI era. Teams can generate UI faster than ever, but they still have to guarantee that what they ship is usable, secure, and maintainable. Accessibility sits squarely inside that problem.

Treating accessibility as an operational capability — on par with privacy, security, reliability, and observability — rather than a compliance exercise changes how you build, not just what you ship.

Snapshots Don’t Scale

The traditional approach to accessibility is the one-time audit: hire a firm, get a list of 200 findings, fix some, and file the report. Audits aren’t useless. For sales, procurement, and governance, they’re essential — a buyer asking for a VPAT or an ACR needs documentation, and legal needs evidence of compliance.

But audits don’t catch problems before merge requests, they can’t inform sprint planning, and they don’t scale with deployment velocity. Six months after an audit, dozens of releases and a redesigned nav make the report fiction. Compliance is not a state you reach; it’s a state you maintain as complexity compounds against you.

The data backs this up. The WebAIM Million report, which scans the top million home pages annually, found 95.9% of pages had detectable WCAG failures in its 2026 run, averaging 56.1 errors per page. Page elements jumped more than 20% in a single year — likely driven by AI-enabled development and “vibe coding” — and more elements mean more places to break. Accessibility debt behaves exactly like technical debt: every inaccessible component shipped becomes a future remediation project, with interest.

Any strategy that treats accessibility as a periodic event rather than a continuous property of the system is going to lose.

The Default State of Generated UI

Consider how quickly this arrived. Andrej Karpathy coined “vibe coding” in February 2025 — a way of working where you “fully give in to the vibes” and “forget that the code even exists.” It was meant for weekend projects, but Y Combinator reported that 25% of its Winter 2025 batch had codebases that were 95% AI-generated.

AI-generated UI is inaccessible not occasionally, but by default. Three forces push models toward non-semantic markup: most React code on GitHub is non-semantic “soup,” so models learn from it; human evaluators judge output visually, rewarding looks over structure; and <div onClick> costs fewer tokens than a properly written <button>, so the cheap path wins unless constrained.

A developer testing AI-generated React components across multiple tools documented the pattern. A typical AI-generated sidebar packed ten distinct accessibility failures into twenty-nine lines: no landmark, no heading, no list structure, click handlers instead of buttons, missing aria-expanded, no keyboard handling, unlabeled icons. The accessibility tree came back flat and unstructured. “Same pixels,” as the author put it. “One is a door. The other is a painting of a door.”

Connect this to security and you see the same root cause. Veracode’s 2025 GenAI Code Security Report tested large language models across dozens of coding tasks and found widespread security vulnerabilities, including OWASP Top 10 flaws. Cross-site scripting was especially common, and newer, larger models didn’t meaningfully improve. The issue wasn’t model intelligence — it was process: generating without constraints and accepting output without verification.

The shortcut that skips the security review skips the accessibility review. AI didn’t create the accessibility gap, but it has industrialized it. The fix isn’t banning AI — developers are already using it. The fix is constraint and verification: treat AI as a very fast teammate that always needs guardrails.

Guardrails Don’t Cost Velocity

The predictable objection is that guardrails slow teams down. In practice, the opposite tends to be true.

Shift-left thinking — catching issues as early as possible — is the entire DevOps thesis, and it applies cleanly here. An accessibility issue caught during design review is a comment; the same issue found in production is a remediation project. Fixing markup while a component is being built takes minutes. Discovering the problem in a late-stage audit means diagnosing the root cause, restructuring the markup, writing tests — hours per finding, multiplied across hundreds of findings into weeks of unplanned work.

Teams that integrate accessibility into everyday workflows avoid the expensive surprises: emergency audits, remediation sprints, procurement blockers, and redesigns that quietly break core journeys. Accessibility doesn’t reduce velocity. Unexpected work reduces velocity. In-flow accessibility is a way of eliminating unexpected work.

Infrastructure, Not Heroics

Organizations that scale accessibility don’t rely on individual effort. They rely on systems.

The highest-leverage starting point is the design system. One accessible component reused a thousand times beats a thousand audit findings. The GOV.UK Design System is a useful reference: its components undergo both automated and manual testing with assistive technologies like JAWS, NVDA, VoiceOver, and TalkBack. The team is explicit about automation’s limits and supplements tooling with user testing involving people with disabilities. They’re equally clear that a design system doesn’t “magically” make a service accessible — it just raises the starting point.

From there, accessibility moves into the engineering workflow:

• Accessibility requirements sit in the Definition of Done.
• Pull request reviews include explicit accessibility checks.
• Interactive controls use semantic elements (<button>, <a>) by default.
• Keyboard navigation and focus management are standard engineering concerns, not optional polish.

Finally, automation makes it enforceable:

• eslint-plugin-jsx-a11y catches issues before commit.
• LevelCI, Pa11y, and similar tools run automated checks in CI/CD pipelines.
• @storybook/addon-a11y surfaces problems during component development.

Accessibility then stops depending on memory and starts depending on process. It becomes part of your platform.

Patterns That Actually Hold

Several implementation patterns show up consistently in teams that do this well.

Constrain AI Before Generation

Instead of fixing accessibility after the fact, bake requirements into tooling via Cursor rules, Copilot instructions, or repository-level standards. Tell the model to use semantic HTML, when to choose buttons versus links, and how to expose state and labels. Models follow persistent constraints far more reliably than one-off prompts.

Stop Hand-Rolling Complex Widgets

Comboboxes, menus, tabs, and modals routinely become accessibility hotspots. Libraries like Radix UI, React Aria, and Headless UI already solve many of these problems. The scalable approach isn’t reimplementing accessible behavior correctly each time — it’s inheriting it from well-tested primitives.

Capture Accessibility at Design Handoff

Focus order, labels, heading hierarchy, and interaction states should be specified before implementation starts. If accessibility requirements are absent from the design artifact, they tend to be absent from the final product. A simple memo covering tab order, labels, and error states at handoff removes a huge amount of guesswork downstream.

None of these patterns is exotic. They’re just DevOps and platform thinking applied to accessibility — treating it as something you operate continuously rather than something you inspect occasionally.

From Compliance To Competitive Edge

Legal requirements are tightening, but they are only a slice of the story. Digital accessibility lawsuits in the United States have remained in the thousands each year and now hit companies of all sizes, not just big enterprises. The European Accessibility Act is likewise enforceable across the EU, covering e-commerce, banking, ticketing, telecoms and more — regardless of where the vendor is headquartered. Regulators are no longer treating accessibility as optional.

The commercial argument is just as pressing. The World Economic Forum estimated in December 2023 that the world’s 1.3 billion people with disabilities, along with friends and family, control $13 trillion in spending power; disabled consumers alone hold about $8 trillion in annual disposable income, according to the Valuable 500. In the UK, the Click-Away Pound Report 2019 measured that figure at £17.1 billion — more than 4.9 million users with access needs who abandon inaccessible sites and take their money to a competitor, a rise of nearly 45% from £11.75 billion in 2016. Unhappy users do not file tickets; they simply buy elsewhere.

For B2B and government sales, accessibility documentation has moved from a nice extra to a gatekeeper. The Seventh Annual State of Digital Accessibility Report from Level Access found that 75% of organizations now demand proof of accessibility at least most of the time when purchasing digital products — roughly steady from 74% — but the share that always require it jumped from 27% to 31%. An accurate VPAT or ACR speeds up procurement. A weak one, or its absence, creates redlines that stall or kill the deal before your product gets a fair evaluation.

Accessibility As A Signal Of Engineering Discipline

Looking past the checklists, accessibility is a reliable proxy for how mature an engineering organization is. Teams that routinely ship semantic HTML, manage focus transitions, expose state properly and enforce those checks in CI tend to ship code that is maintainable, testable and less prone to bugs. The same discipline that produces a usable component for a screen reader also produces one that holds up in production.

For development and product leaders, that is the actual business case: accessibility work is platform work. It repays itself every time a feature ships with less rework and fewer surprises. A team whose foundations are accessible ships faster on each subsequent feature, not slower — the inverse of the scrappy, fix-it-later approach that racks up technical debt.

Built On Systems, Not Heroes

The core insight to internalize is simple: accessibility is not delivered by an audit, a single champion, or a last-minute remediation sprint before launch. It emerges from systems that run continuously.

• An accessible design system gives components a correct starting point.
• A Definition of Done keeps them correct as they evolve.
• Automated tests and CI gates make regressions fail the build instead of shipping silently.
• Governance ensures someone is accountable for the overall state.
• Guardrails on AI-assisted development keep your fastest tool from becoming your biggest liability.

None of these practices is glamorous, and that is exactly why they work. They belong to the same family of unglamorous, reliable processes that already protect your security, reliability and performance. The tools catch mechanical failures, but they cannot tell you what it feels like to use your product when you are blind and navigating with a screen reader, or when you depend entirely on a keyboard because a mouse is not an option.

Build those systems — they are the only way accessibility can survive a real release schedule. But pair them with regular testing sessions involving real users with disabilities. The first time you sit behind someone using JAWS to fight through a form your team declared “done” is transformative. Automated tooling reports whether you passed a check. A user tells you whether the product actually works.

Accessibility is not a feature to be bolted on. It is an operational capability, and treating it as such yields what engineering leaders care about most: a faster, safer and more reliable release process.