The W3C just put the accessibility overlay lie in writing

When we started building Jeikin, we made a pragmatic bet grounded in how software actually gets written. We knew firsthand that the real friction in accessibility has never been a lack of ethics inside organisations. It's a lack of incentives. Nobody rewards a developer for spending hours fixing a component's semantics or combing through an accessibility tree. They're rewarded for shipping features fast. If fixing accessibility means stalling the sprint to do tedious manual work, it simply doesn't get done.

So we bet on using AI to clear away the maximum number of those technical issues, the ones that generate friction and stall teams, and freeing people to step in only where the algorithm has no context. Meanwhile, the market was selling the opposite lie: the bullshit of magical automation. "Install this script and I'll hand you 100% compliance on a green chart." We built a tool that refuses to mark the parts a machine can't judge as done, but that sweeps up everything automatable and keeps an auditable record of every step. A harder sell to a buyer who just wants to cover themselves with a number. It was the only honest one.

On July 23, the W3C published WCAG-EM 2.0, the official methodology for evaluating conformance with WCAG. Which confirms we didn't exactly reinvent the wheel. The hybrid evaluation model has been on the table for years. What actually matters is that the W3C itself has finally put in writing the hard truth half the industry works to hide: that pure automation is a commercial fantasy, and that evaluating accessibility demands combining mechanical rules to kill friction with the human judgement no algorithm has.

The part the "quick-click" industry didn't want in writing

WCAG-EM is five steps, and you can find the sugar-coated summary on any corporate blog. But the part that draws a line in the sand is two sentences most people skip, because they destroy the business model of everyone selling absolute certainty and cheap compliance badges.

The standard says, in plain text, that "most accessibility checks are not fully automatable." And it finishes: "using this methodology alone does not result in being able to make WCAG 2 conformance claims."

Read that twice if you've ever bought an automated scanning tool thinking it shielded you legally. The W3C itself, the body that defines the guidelines, just put in writing that no tool, on its own, lets you declare conformance. Not ours. Not anyone's.

We wired that boundary into Jeikin early on. AI and the scanner take on the mechanical layer: contrast, labels, heading hierarchies, ARIA syntax errors. That's the repetitive part nobody was getting credit for anyway, and now it handles itself. Everything past it, roughly two-thirds of WCAG, is judgement about whether a real person can use the thing, and that stays with a human on purpose. Instead of stamping the report with a fake green check so the client sleeps easy, we hand the hard call to the person qualified to make it. What looked like throwing rocks at our own commercial roof turns out to have been the official method all along.

Why this approach is urgent in the age of AI-generated code

If accessibility couldn't be reduced to a number three years ago, trying it today is suicidal. The reason? The way we build software has changed radically: AI now writes and ships code at breakneck speed, generating interfaces that look visually perfect on a monitor but are completely unusable for someone on assistive technology.

The old audit model is dead: the one traditional WCAG-EM assumes, where you call a consultancy once a year to review a static sample of your product before a big launch. Nobody ships like that anymore. Interfaces change daily, get generated by the dozen, and go up unverified. A yearly analysis can't handle that firehose.

That's why the evaluation the standard demands can't be an annual meeting on the calendar. It has to be embedded in the continuous development pipeline, acting as a filter in the same loop where the AI generates the code, cutting developer friction in real time.

What Jeikin is today, now that the market has a name for it

Jeikin is the engine that runs the WCAG-EM 2.0 evaluation cycle continuously, inside AI-assisted development environments.

Our tool squeezes automation to clear every mechanical issue that slows engineers down, routes the criteria that need real context of use to a human, and records the outcome of every test as reproducible evidence, exactly what the standard's final step demands. If a client, a public audit, or the legal team asks tomorrow whether your site is accessible, you don't cross your fingers and show a green chart with no legal weight. You pull the exact record of tests, methodologies, and evidence, human and automated alike.

"Is your site accessible?" is a question about evidence. What you checked, how you did it, and what you'd have missed without a human looking. That record is the answer, and about time the W3C said so.