The accessibility of documentation published in Confluence

Published 7 September 2026, widened 9 September, recounted 7 October. 1,182 pages across 13 public Confluence Cloud sites, measured against WCAG 2.2 by the Clarable rule engine.

Corrected on 7 October

The first version of this page counted several habits as failures that WCAG does not treat as failures on their own: a bare URL used as link text, an H1 inside the page body, a skipped heading level and an empty heading. A reader showed us the first of these, and checking the rest against WCAG found the others. A URL names its own destination, and success criterion 2.4.4 lets the sentence around a link explain it. WCAG does not require heading levels to run in sequence. We also reported a table used only to lay out images as a data table without a header row, which it is not.

We fixed the checker and measured again on a fresh random sample. Those habits are now reported as advice for review, and they no longer count against a page. The earlier figure, "roughly half" of pages with no level A or AA failure, is replaced below.

What we found

Read the headline figure as two pages in three, not as a precise percentage. A fresh random sample of the same sites can move it several points on its own; the section on method sets out why.

A handful of checks account for most of what fails

This is the finding that matters, because it says the problem is smaller than it looks.

Every one of these is mechanical. None needs a specialist to find, and none needs a redesign to fix. A documentation estate failing on all of them is not badly built; it is unmeasured. Two are reported for a person to confirm rather than as certain failures: bold used as a heading, and "click here", which can be acceptable when the sentence around it says where it goes.

Three habits are common and do not fail WCAG on their own: bare URLs used as link text (846 instances on 293 pages, every site), an H1 inside the page body (636 on 178 pages) and skipped heading levels (137 on 76 pages, every site). All are worth tidying. None is a barrier, and we no longer count them as one.

Each check, with the editor step that closes it, is written up in the checks behind most of it.

Contrast is concentrated, not spread

1,396 contrast issues sit on just 114 pages. That is almost always one template or one colour, chosen once and repeated. It is one of the largest problems by volume and one of the smallest to actually fix: change the value, not 114 pages.

The alt text problem is not the one people think

Missing alt text is the most widespread certain failure, on 285 of the 1,182 pages. That is the expected result.

The unexpected one sits below it: 258 further issues where alt text was written and does not describe the image. Filenames, the word "image", a caption repeated from the paragraph above. Somebody filled the field in and the information is still gone.

That distinction matters for how you fix it. The first group needs a policy. The second needs the authors to understand what the field is for, which is a different and slower piece of work.

Software docs are cleaner than knowledge bases

Seven of the sites are public knowledge bases, mostly in education; six are open-source software projects and research-computing docs, added to widen the frame. The software docs came in cleaner: 71% of pages with no A or AA failure, against 57% for the knowledge bases.

The difference is in the kind of failure. Missing alt text sat on 17% of the software pages against 32% of the knowledge-base pages. Bold used as a heading went the other way, on 16% of software pages against 8%. That is the failure of writing fast in plain text, rather than the failure of a rich page.

No site was clean, and the range was wide

Per-site, the share of pages with no level A or AA failure ran from about a third to nearly nine in ten. The best site in the sample still had roughly one page in eight carrying a failure; the weakest had two in three.

Missing alt text and contrast failures each appeared on twelve of the thirteen sites. Neither is specific to one organisation's habits; both come from how documentation is written everywhere.

Method

1. Site selection. Thirteen publicly readable Confluence Cloud sites, found through ordinary web search. All serve their content to anonymous visitors by their own configuration. Seven are public knowledge bases; six are software-project and research-computing documentation, added to widen the frame beyond education.
2. Page selection. The full public page list was enumerated for each site, then a random sample of up to 100 pages drawn from it. This matters more than it sounds: an early run took the first pages of each space and reported 90% clean. Those are landing pages — short, no images, no tables. Sampling from the top of a documentation tree measures the part with the least content in it.
3. Sampling error. At 100 pages per site the figure carries real noise. Re-drawing the same sites has moved it by up to eight points from the sample alone. Treat the precision as about plus or minus eight points, and the honest claim as "between a half and three quarters".
4. Measurement. Page bodies were read in Atlassian Document Format, the same input the product uses, and evaluated by the same 32 rules across 14 WCAG 2.2 success criteria. No conversion step, so no fidelity lost. A failure is counted only where a rule is certain; everything that needs human judgement is reported for review and does not count against a page.
5. Politeness. Each site's own robots.txt was read and its stated crawl-delay honoured. Only content served publicly was requested.
6. Reporting. Aggregate only. No site is named, here or anywhere else.

What this does not show

Thirteen sites is still a small sample, and they were not randomly selected from all Confluence sites — no such list exists. They are the sites that serve their content without an account, which is its own kind of selection.

Nor does it measure everything. The engine tests 11 of the 55 level A and AA success criteria in WCAG 2.2, and part of WCAG cannot be decided by any tool: whether reading order matches meaning, whether a description is adequate, whether captions are accurate. Those criteria are reported as needing review, never as passing.

So: treat this as a first measurement of a thing nobody had measured, not as a settled figure. We would rather publish a number with its limits attached, and correct it in public when we get something wrong, than a rounder one without them.

Why we ran it

We build an accessibility checker for Confluence, so we had both the engine and the reason to care. That is a conflict worth stating plainly. It is also why the method is written out above in enough detail to be repeated by someone who wants to check us.

Measure one of your own pages