Build1 publisher3 min readPublished
Coding agents learned markup from a web where 96% of homepages fail automated checks
WebAIM found accessibility problems on 96% of the top million homepages using automated tools alone. That corpus is what coding agents pattern-match against, and the remedy on offer is an instruction file the agent reads every session.
The Engineer · Build desk

What happened
- The WebAIM One Million report found accessibility issues on 96% of the one million most popular homepages, using only automated testing tools that catch a fraction of what is actually there.
- The most common failures were insufficient colour contrast, missing alternative texts and labels, empty links and buttons, and missing document language.
- The post's remedy is to shape code as it is generated, using a session-loaded AGENTS.md for always-applicable rules and a conditionally loaded skill file carrying the WAI-ARIA authoring hierarchy.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A scanner in CI can only prove the machine-detectable defects are gone, because the 96% baseline came from that same class of tool; a team reading a green build as WCAG conformance is treating that partial pass as the whole standard.
- decision Instruction files and skills both sit in the context window and neither blocks a merge, so each team has to decide whether it trusts a conditional trigger or puts a blocking check in the pipeline.
- cost The commonest failure classes are the cheap ones to automate, which leaves everything the scanner cannot see as recurring human review time on every component an agent writes.
- contradiction The post's volume evidence covers code in general, so the claim that agents regress to inaccessible markup stands as an inference from the training corpus, with no measurement behind it.
Four percent of a million pages passed. That works out to 40,000 homepages in WebAIM's top million where the automated pass found nothing [19]. Automated tools detect only a fraction of the accessibility problems present, so 40,000 is a ceiling on the clean examples in that slice of the web [2].
The corpus argument itself is simple. A coding agent returns the statistically likely completion, drawn from the internet-scale data set it was trained on, according to the dev.to post by josefine [7][18]. If the common pattern in that data is a div carrying `role="button"`, that is what comes back. Writing the rule out explicitly, the post says, stops agents from reflexively sprinkling role="button" on elements that should just be `<button>` [13].
The two carriers she describes load differently, and that matters more than their contents. AGENTS.md, or claude.md, is pulled into every session, so the advice is to keep it concise and restricted to rules that always apply, along the lines of "semantic HTML by default" and "WCAG 2.2 AA compliant" [9]. Skills load only when the agent recognises that a task matches one, and a skill that never fires leaves no trace in the diff [10]. The post asks you to define when the skill applies, which files and areas it covers, and how its activation gets communicated [11].
The rule worth encoding is the WAI-ARIA authoring hierarchy: native HTML element, then native HTML with attributes, then ARIA only if nothing native covers the case [12]. The post also recommends documenting prohibitions, such as "do not use raw hex values when semantic tokens exist", and asking the agent to justify any ARIA it adds outside a native element [15][14]. Your own documentation or design system goes in as the highest-priority source of truth [17].
Both levers live in the context window, and both are advisory. Neither one blocks a merge. The case for a check that does block sits in the failure list: every class on it was surfaced by an automated scanner, so every class on it is in scope for a scanner running in CI [20][3]. The same detector also sets the limit on what a green build proves: the 96% baseline came from tooling of exactly that kind, so passing it means the common defects are absent and the rest goes unmeasured [1][2]. Josefine's own conclusion is that fixing this at scale needs better systems and governance [22].
The post never measures agent output. There is no comparison of defect density in agent-written markup against human-written markup, so the regression claim runs from the training data to the expected result [21]. The volume figures it cites cover code in general: pull requests up 23% and commits up 25.1% against the prior year, with 36 million new GitHub users in 2025 [5]. WebAIM, quoted in the post, said home pages "are getting larger and more technologically complex at an alarming rate, making accessibility more difficult to achieve and maintain" [4]. Josefine quotes Anna E Cook: "AI does not repair broken systems. It multiplies them." [8]
What to watch
- A new WebAIM One Million run: a materially different failure rate changes the corpus premise the whole argument rests on.
- Any published measurement of accessibility defect density in agent-written markup against human-written markup.
- Whether agent vendors ship the WAI-ARIA hierarchy in default system prompts, making them a second carrier alongside per-repo instruction files.