Accessibility-first, not vibe-coded.

It’s not vibe coding. It’s engineering.

“Vibe coding” gets thrown at any software built with AI assistance, as if reaching for an LLM automatically means skipping rigour. The people who actually coined and refined the term say the opposite.

Where “vibe coding” actually came from

Andrej Karpathy coined the term in a February 2025 post:

“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

The term was coined for throwaway projects — never for production engineering.

The industry already drew this line

Simon Willison, one of the most-cited voices on AI-assisted software, drew the distinction explicitly in “Not all AI-assisted programming is vibe coding” (19 March 2025):

“If an LLM wrote every line of your code, but you’ve reviewed, tested, and understood it all, that’s not vibe coding in my book — that’s using an LLM as a typing assistant.”

He calls the disciplined, production-grade practice “vibe engineering”3 — AI used inside testing, code review, source control and planning, with deep understanding of what shipped. That’s the practice this page is describing.

GitHub’s own guidance says the same thing

GitHub’s official Copilot documentation doesn’t sell AI-assisted code as a shortcut around rigour either:

“While Copilot is very powerful, it is still a tool capable of making mistakes, and you should always validate the code it suggests.”

“Use automated tests and tooling to check Copilot’s work.”

ChatLemur’s own rigor

Here is what that looks like in this codebase, verified against the shipped repository rather than asserted:

• A two-layer evaluation harness for Lenny’s voice conversation quality — one deterministic layer (regex/heuristic scoring, no LLM cost) and one LLM-as-judge layer for subjective qualities — wired into continuous integration.
• A real behavioural eval, not a mock. A separate harness hits the live brain with real LLM calls and asserts actual behaviour — answers versus refusals, safety guards, intent — specifically because a purely mocked test suite had stayed green while the live product was broken.
• A large automated test suite on both platforms. The backend Python suite collects in the thousands of tests via pytest; the iOS companion app carries an automated XCTest suite of similar scale across hundreds of test files.
• Deploy-gating smoke tests that must pass before a release reaches production.
• A dedicated security test suite, including automated penetration and session-security tests.

Accessibility isn’t charity — it’s how quality software is built.

Accessibility gets treated as a compliance tax, or worse, a kindness. The people who build the platforms and the testing tools disagree: accessibility and test-automation quality run on the same underlying layer.

Apple: the same framework runs both

At WWDC 2025, in the session on UI automation with Xcode, Apple said this plainly:

“The thing is, accessibility is the underlying framework that powers UI automation.”

“Having a great accessibility experience means you get a great UI automation experience too.”

The accessibility tree is the test-automation interface

This isn’t an Apple-only idea. Playwright’s recommended way to locate elements is by role and label — the accessibility tree.6 Testing Library puts the same idea at the centre of its guiding principle:

“The more your tests resemble the way your software is used, the more confidence they can give you.”

An interface with no accessible name, no role, no label is invisible to that layer — which is exactly why it’s also invisible to a screen reader. Build the accessible structure and the reliable automated test comes for free; skip it and both break together. Open-source engines like Deque’s axe-core exist specifically to automate that check inside an existing test suite.

It benefits everyone, not just disabled users

“Web accessibility also benefits people without disabilities, for example: people using mobile phones, smart watches… older people with changing abilities due to ageing; people with ‘temporary disabilities’ such as a broken arm or lost glasses; people with ‘situational limitations’ such as in bright sunlight or in an environment where they cannot listen to audio…”

Microsoft’s Inclusive Design team frames the same insight as a design method:

“Solve for one, extend to many.”

“Everyone has abilities and limits. Creating products for people with permanent disabilities creates results that benefit everyone.”

The industry mostly doesn’t do this

94.8% of the top one million home pages had detected WCAG 2 failures — an average of 51 errors per page.

Overlays are not the shortcut they’re sold as

More than 800 accessibility professionals — including authors of the WCAG, ARIA and HTML specifications, and accessibility staff at Google, Microsoft, Apple and Shopify — have signed the Overlay Fact Sheet, which states plainly that automated accessibility overlays “are not an effective means of ensuring accessibility.”12

In Australia, it’s already a legal right

In Maguire v SOCOG (2000), Bruce Maguire, a blind man, won before the Human Rights and Equal Opportunity Commission after the Sydney Olympics website was found unlawfully inaccessible. The Sydney Organising Committee for the Olympic Games was ordered to fix the site and pay $20,000 in damages — one of the world’s first web-accessibility legal wins, decided under the Australian Disability Discrimination Act 1992.13

The cost of ignoring accessibility is real

Accessibility failures aren’t just a quality gap. They are actively litigated and fined across the US, the EU, Australia and Canada.

• USA — Target, 2006–2008

  A class action over Target’s inaccessible website settled for $6,000,000 — the first major e-commerce web-accessibility case in the US, establishing that retailers with physical stores must also make their websites accessible.14

  The Lesson: if you have physical stores, your website is treated as part of them — and inaccessibility is a class-action risk, not a cosmetic one.

• USA — Robles v. Domino’s Pizza, 2016–2021

  A blind screen-reader user sued after he couldn’t order online. The 9th Circuit held that the Americans with Disabilities Act covers websites and mobile apps; the US Supreme Court declined to hear Domino’s appeal in October 2019, leaving the ruling in force. In 2021 the court ordered Domino’s to conform to WCAG.15

  The Lesson: the ADA reaches your website and your app. “It’s only an app” is not a defence — the highest court let that ruling stand.

• USA — the volume is rising

  More than 4,000 digital-accessibility ADA lawsuits were filed in 2024, and more than 5,000 in 2025 — a roughly 20% year-on-year rise.16

  The Lesson: this is a rising tide, not a one-off — thousands of businesses are sued every year, and the count keeps climbing.

• EU — European Accessibility Act

  Enforcement began 28 June 2025. Private-sector digital products and services must be accessible, with fines up to €100,000 and national ceilings reaching roughly €1M in Spain and €1.26M in Hungary.17

  The Lesson: since 28 June 2025, shipping an inaccessible digital service into the EU is a fineable offence, not a backlog item.

• Australia — Coles, 2014–2015

  A blind woman who uses a screen reader sued Coles under the Disability Discrimination Act 1992 because its online shopping site took her up to eight hours to use. Coles settled and agreed to make the site accessible.18

  The Lesson: in Australia, an online store a blind customer can’t use in a reasonable time is unlawful discrimination — the law already covers this.

• Australia — Maguire v SOCOG, 2000

  $20,000 in damages, and the Sydney Olympics website ordered fixed — see above.13

  The Lesson: Australia has enforced web accessibility since 2000. This is settled law, not a new frontier.

• Canada — AODA (Ontario)

  Corporations face fines of up to CA$100,000 per day until a violation is resolved.19

  The Lesson: in Ontario, non-compliance is metered in dollars per day — delay compounds the bill.

WCAG 2.1 AA is not a nice-to-have. The 94.8% of sites that fail it are carrying real, litigated legal risk on three continents.

The fusion

Put the two pillars together and the insult runs backwards. The same critics who sneer “vibe coding” at fast, AI-assisted engineers are, on the numbers above, shipping most of a web that fails its own accessibility bar — untestable by the accessibility tree, and exposed to the legal risk catalogued above — because they skipped the two disciplines that actually decide software quality: rigorous automated testing and accessibility, which, per Apple, are the same discipline.

Not alone

This intersection isn’t a solo act. Saqib Shaikh, a blind engineer at Microsoft, built Seeing AI on exactly this premise — lived assistive-technology experience driving AI product engineering. Be My Eyes’ Be My AI does the same at scale, pairing AI description with a blind and low-vision community that has used it to test it every day. ChatLemur sits in that same tradition — accessibility and AI engineering, built by someone who lives inside both.

Want software built to this standard?

If your product needs to meet the bar this page describes — and stay clear of the legal risk above — I audit and advise on it directly, as a blind engineer who tests the way your users actually work. See the accessibility consulting service →