Who checks the checker?

On 6 August, Vercel, AWS, GitHub, Microsoft, OpenAI and the makers of Cursor agreed on a common format for the add-ons that extend AI coding assistants. Write one useful set of instructions and it now works everywhere, instead of needing a rewrite for each tool. Anthropic, whose instruction format the whole thing is built on, is not among the signatories.

It is a distribution standard, which is very likely why six rivals could sign it inside a week. It settles how an add-on is delivered and says nothing about whether it is any good. So an add-on promising to handle your accessibility can now reach every major coding tool, and nothing along the way asks it to prove it works.

A dozen or so accessibility add-ons are already moving through that pipe, and we have spent time working with the two most popular ones. Not to find out whether they catch problems, because everything catches problems, but to understand what happens around the catching. Does anything confirm the fix actually worked? An assistant will tell you it fixed something because it made a change that looked right, and sometimes it did. And does a record survive afterwards? Accessibility is a legal requirement in Europe now, so the work eventually has to be shown to a client, a buyer or an auditor.

Both toolkits are free, run entirely on your own machine, and send nothing back to a vendor. AccessLint is the tighter of the two, scanning a page, inspecting it through a browser, fixing what it finds and watching for anything that breaks again later. Accessibility Agents is much larger, with eighty specialists behind it and roughly 24,000 lines of guidance, each piece citing the official standard it comes from.

The first question: do they check their own work?

They do, and this is where both are better than I expected.

AccessLint refuses to guess. It examines the page before touching anything, makes its change, examines the page again the same way, and compares. If the original problem survived, or the repair broke something else, it stops and says so rather than quietly having another go: "Verification fails (a new violation appeared, or a targeted one remains): report it and stop. Don't iterate silently."

It also sorts every finding by how much confidence the evidence actually supports, separating what a machine confirmed from what still needs a person, and both of those from what can only be settled by someone using a screen reader. Then it does the honest thing with that distinction, which is to refuse the shortcut this whole industry is tempted by:

Real AT-user testing is ○: named, handed off, not emulated. No personas, no synthetic sessions, no predicted behavior.

A free tool that will not let a language model imagine how a disabled person experiences a page, and write that down as though someone had checked, was built by people who understand what they are dealing with.

Accessibility Agents goes further still and builds something that genuinely blocks. Try to change anything users will see, and the change is refused until an accessibility review has happened. The authors closed the obvious ways around it, too, so a renamed file will not slip past. Then, in comments in that same file, they write down exactly what it is worth:

Note: The marker has no expiry. After one accessibility-lead consultation, all subsequent UI file edits are allowed for the remainder of the session.

So the lock proves an accessibility specialist was consulted once, and everything after that goes through unimpeded, reviewed or not. It behaves rather like a doorbell, and to their credit the authors say so themselves rather than calling it enforcement in the sales copy.

The second question: does a record survive?

Here they part company. Accessibility Agents keeps its audits, written into your project alongside your code. AccessLint keeps nothing at all, printing its report into the conversation where it disappears when you close the window.

The more useful thing to notice is the shape both of them share, and it is the shape of nearly every tool in this category. They are self-contained. Your assistant decides what is wrong, your assistant fixes it, your assistant confirms its own fix, and your assistant writes the record. Nothing external enters the loop at any point: no second model arguing the opposite case, no person who has to sign anything off, no service that saw what happened independently.

Your project

Your assistant

Anyone external

1. Step 1, Your project:

   Has a problem

2. Step 2, Your assistant:

   Finds and fixes it

3. Step 3, Your assistant:

   Confirms its own fix

4. Step 4, Your project:

   Stores the record

5. Step 5, Anyone external:

   ✗Never enters the loop

That is not a flaw anyone introduced by accident. It follows from running entirely on your own machine, which both projects chose deliberately and which buys real things: nothing reported back to a company, no account required, everything staying with you. A closed loop is the price of that, and for most day-to-day work it is a price worth paying.

It does mean the output is self-reported by construction. For following your own progress, that is completely fine and I would use it. When a customer asks you to demonstrate that your product meets the standard, that is still what you are handing them.

Where this leaves things

None of this is a complaint about these two projects, which are careful and free and better than most of what you can pay for. Keeping count was never what a skill was for. It is a recipe book, it says how the work is done, and holding it to a standard it never claimed to meet would be unfair.

The useful question is what you are choosing when you install one. A closed loop is the right shape for a great deal of work. It is the wrong shape whenever the answer has to satisfy somebody who was not in the room, which is most of what the word compliance covers, and no amount of improvement inside the loop changes that, because the limitation is architectural rather than a matter of quality.

So: if you want to stop shipping things that break for people using a screen reader, install one of these two today. If you also need to show your work to somebody outside your team, notice that you are looking at a recipe book, and that a recipe book is not the whole kitchen.

---

Quotes are from the projects' own public repositories, as they stood on 11 August 2026: AccessLint/skills and Community-Access/accessibility-agents. Both are open source and worth your time.