Your files are ready.

The full report.

The fastest-growing class of broken websites in 2026 is the kind a person built in an afternoon without writing a single line of code.

Gartner expects 60% of all new code to be AI-generated by year-end, while GitHub says we’re already at 46%. With 92% of US developers using AI tools every day, a huge chunk of the web is being shipped by people who have never written production code and will not think about accessibility unless a tool reminds them to.

The 2026 WebAIM Million report shows that 95.9% of top homepages have detectable WCAG failures, and that number is still climbing. The average page now has 56 distinct errors, with low-contrast text failing on nearly 84% of them. ARIA use has jumped 27% year-on-year, but much of that is just AI hallucinating code that looks accessible without actually doing anything useful.

In Australia, the timing is tight. The Human Rights Commission doubled down on WCAG 2.2 AA as the digital standard in 2025, and new federal services are now required to meet it. Meanwhile, Anthropic, the team behind Claude, opened their Sydney office in April 2026. The technology is arriving here just as the legal and policy consequences are setting in.

In the last few weeks, the experts have built five major projects for Claude accessibility. But none of them are really for the person Pounce sees most: the founder or marketer vibe-coding a landing page over the weekend with zero background in accessibility. That gap is why we wrote this piece, and it is exactly where our new starter CLAUDE.md file comes in.

Before any argument about gaps, let’s have an honest look at the work already done.

The 2026 Claude accessibility tools landscape

What none of these tools serve

Each of these five projects is good. Each was built by someone closer to the work than I am. The honest read across all of them: they assume the user already knows what WCAG is, has installed an IDE, and is willing to invoke a specialist when needed.

That is not the user Pounce keeps seeing. The user we keep seeing is the operations manager building an internal tool in three hours of vibe coding on a Friday. The marketer spinning up a campaign landing page who has never opened DevTools. The founder prototyping with Claude Code because they cannot afford a developer yet.

For those users, the existing tools have two problems. Awareness, because they do not know the tools exist and will not search for them. And, more interestingly, even when an expert installs the right tooling, the LLM default behaviour still pulls the work back towards inaccessible output.

Taylor Arndt’s headline, “I Told Claude Code to Use My Accessibility Agents. It Did Not Listen.”, is the cleanest statement of this. Skills and agents are pull-based; the model decides if they are relevant. The thing that does work, on the evidence available today, is a system prompt: a CLAUDE.md file the model reads before it writes a single line of code.

The hypothesis: would a starter CLAUDE.md raise the floor?

The claim is narrow. Not “would it produce WCAG-passing websites” — it would not. Not “would it deliver WCAG compliance” — it cannot. The claim is whether a single set of plain-English rules, dropped into a Claude Code project before the first prompt, would reduce the most common accessibility failures in AI-generated output.

The case for. Claude knows about accessibility when prompted. The deficit is in defaults, not in knowledge, and a CLAUDE.md shifts the default. Guha’s track record is the proof case: 14 production Next.js apps, 350 screens, all passing WCAG 2.1 AA, with a system prompt as the first step.

The case against. A CLAUDE.md cannot test what it cannot see. The most expensive failures are runtime: focus traps that leak, screen-reader announcements that never fire, modals that look fine in code and break the moment NVDA touches them. Prompt-layer rules can prevent known anti-patterns; they cannot verify that the output actually works for disabled users.

The honest conclusion. A starter CLAUDE.md, written carefully and honest about its limits, is a valuable contribution to the lowest-prepared part of the vibe-coder market. It will not produce WCAG-passing websites. It will produce websites that are meaningfully more accessible than the current default, which is almost nothing.

What the starter CLAUDE.md should do

The principle is restraint at the language layer, not at the rule count. Plain English. No jargon unless defined. Drop-in placement. Zero claims that the file produces compliance.

The file is written as direct instructions to the model, not as a human guide. It treats the prompting user as someone who cannot evaluate accessibility output themselves and will not catch failures themselves, which is true. Rules are imperative, opinionated, and framed as non-negotiable defaults.

The closing sections are user-facing and travel with the rules: what the file does not do, when to bring in a professional, and a version-and-feedback note so the file can be updated as the models change.

The language discipline matters as much as the rules. The file describes its output as more accessible than the default, reduces the worst accessibility failures, and a starting point for accessibility. It never describes its output as accessible, WCAG compliant, or meeting the standard.

What the file does not try to be: a complete accessibility checklist. The W3C publishes WCAG 2.2. The WAI-ARIA Authoring Practices Guide exists. Each of the five projects above publishes more comprehensive coverage. The starter file’s job is to be the first file a vibe coder ever drops in: the floor, not the ceiling.

Pounce ships v1 today. A v2 in December will include lived-experience panel review and a published changelog. Both versions are free. Neither produces compliance. Both, on the evidence available, raise the floor.

Sources and further reading

The starter file referenced in this article — CLAUDE.md, plain English, drop-in to any Claude Code project — is available as a free download alongside this piece.