How we audit a website builder

Headroom is a number out of ten describing how much accessible ground a platform hands you before you start working, and how hard that ground is to ruin.

It is not a compliance score. It is not a rating of any finished website. It is not a prediction about whether you will be sued, and it does not vary by jurisdiction because it is not about law at all. A platform scoring highly can be used to publish something completely unusable, and platforms scoring lower have produced excellent sites in careful hands.

Five things go into it, weighted roughly in this order:

1. What arrives switched on. A visible focus indicator, a skip link, semantic landmarks, labelled form controls, a language attribute. Things you inherit are things you cannot forget.
2. Whether the fields exist. Alternative text has to have somewhere to go — in every image context the editor offers, not only the main image block. Same for captions, transcripts and link text.
3. How hard the defaults are to break. A theme system that makes a heading level a styling choice is a system that will produce broken heading order, every time, on every site.
4. Whether the platform helps you find problems. A built-in checker is worth real points, but only for what it can genuinely detect.
5. How honest the documentation is. Platforms that tell you plainly that they cannot guarantee compliance score better than platforms that imply they can, because that sentence changes what a buyer does next.

• 8.0 and above — wide headroom. Strong defaults, the fields are all present, and either the markup is under your control or the platform actively looks for problems.
• 6.5 to 7.9 — workable headroom. Reasonable defaults with real gaps, usually the absence of any way to discover your own failures.
• 5.0 to 6.4 — narrow headroom. You will be doing most of this yourself, and the platform will occasionally work against you.
• Below 5.0 — you are doing the work. The platform is not helping and may be actively producing problems you then have to undo.

We do not say anyone will be compliant. Not on the money page, not in a headline, not in a meta description written to catch a search. Compliance is a legal determination about a specific site and we are not in a position to make it. Nothing on this site is legal advice.

We do not invent legal facts. No lawsuit counts, no settlement totals other than a regulator's own published order, no characterisations of what a court has held, and no invented success criterion numbers. Where a regulation is described, only what its text says, with the date. Every criterion number printed anywhere on this site appears on a table in the repository's FACTS file, with a link to the specification.

We do not take money from accessibility overlay vendors. Several run generous affiliate programmes. We are not in any of them, and no overlay vendor exists in this site's affiliate configuration, so there is no mechanism by which one could be linked. The overlay assessment is the reason.

We do not print numbers we cannot trace. There is a widely quoted figure for the proportion of accessibility failures automated tools catch. We could not follow it back to a methodology we were able to read, so it does not appear here. There is a whole industry of ADA lawsuit counts published by firms selling remediation. None of them appear here either.

We do not print builder prices. They drift, they are not what this lane is about, and a stale price is a needless way to be wrong.

The honest limits, which are substantial.

We have not hands-on tested every builder's editor with assistive technology. Doing that properly means testing each admin interface with several screen readers across several operating systems, and we have not. Assessments here are of documented capability and of the output those platforms are documented to produce. Where a description depends on a vendor's own documentation, the page says so.

Documentation drifts faster than pages do. Builders ship accessibility changes without release notes. Everything here was checked against current vendor documentation on 19 September 2026, and the honest expectation is that some of it will have moved by the time you read it. Check it in your own editor.

A platform assessment cannot see your site. This is the largest limit and it is structural. The most accessible platform in the world will not stop you writing "click here", using placeholder text as a label, or choosing a grey that fails at 3:1. That is why roughly half of this site is about checks you run yourself rather than products you buy.

Automated testing is a floor, not a verdict. Our own pages are swept with an automated accessibility audit on every route, and we treat a perfect score as evidence that the obvious things are not wrong — not as proof that the pages are good. No automated tool can tell whether alternative text is meaningful or whether a tab order makes sense to a human being.

If a fact here turns out to be wrong, it gets corrected and the change is visible: the re-measured date on the page moves and the entry in the repository's FACTS file is updated with a new verification date. If we cannot verify a replacement, the claim comes out entirely rather than being softened into something vaguer.

If you have found something wrong, the bench wants to hear about it — particularly if you use assistive technology and something here does not work the way this site claims it does.