What validators miss when a coding agent writes your HTML

Raxy — Mon, 09 Nov 2026 16:56:43 +0000

Ask a coding agent for a "Save" button and you sometimes get this:

<div class="btn" onclick="save()">Save</div>

Run it through the Nu HTML Checker: valid. Run it through axe-core: no violations. Ship it.

Now press Tab. Nothing focuses it. Press Enter: nothing happens. A keyboard user, or anyone on a screen reader, cannot use your Save button, and both of the tools you trusted said it was fine.

Why the validators pass it

A <div onclick> is well-formed HTML. Nu checks that the markup is valid, and a div is valid. axe checks the rendered page against a set of known accessibility failures, and a plain div with a click handler does not reliably match a rule it can detect, because axe cannot know the div was meant to be a button.

That is the gap: the mistake is choosing the wrong element, and that choice happens before anything gets validated. No validator run afterwards can recover the intent.

I wrote 9 small before/after examples: a clickable div, a div "modal", a stack of divs used as a list, and so on. 5 of the 9 broken versions pass both Nu and axe. The validators catch the other 4 (a missing alt, a bad heading order, a missing label, a stray tabindex), but they are blind to the element-choice ones.

Measuring it

I built a skill called divorce that does two things: it pushes the agent to use the native element first (<button>, <dialog>, <details>, <ul>), and then it checks the output with Nu and axe and reports pass / fail / not_measured from a script, not from the model.

To see whether the nudge changes anything, I ran the same agent on 8 small UI tasks, 5 runs each: 80 generated pages, half with the skill and half without, and measured every page afterwards.

metric	change (with vs without)
HTML lines	-29%
JavaScript lines	-41%
ARIA attributes	-33%
axe violation nodes	8.2 to 2.0 per run

Two honest caveats:

One number went the wrong way. 3 of the 40 pages written with the skill had Nu validation errors, against 0 of 40 without. It is in the README next to the good numbers.
The eval tool's own score gave both arms the same grade. If I had trusted that score I would have concluded the skill did nothing. The difference only showed up when I measured the actual HTML, which is the whole point of this post.

It is one model on one machine with synthetic tasks, so read it as a direction, not a result. And fewer ARIA attributes is not automatically "more accessible": often the native element simply does not need the ARIA that a div reimplementation bolts on. You still have to test with a keyboard.

The takeaway

If an agent writes your HTML, a green validator is necessary but not sufficient. The cheapest real test is still this: unplug the mouse and press Tab through the page. If you cannot reach a control, no tool was going to tell you.

The skill is MIT, and the raw numbers and method are in the repo: https://github.com/ElRaxy/divorce

DEV Community: Raxy

What validators miss when a coding agent writes your HTML

Why the validators pass it

Measuring it

The takeaway