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
Top comments (0)