Confluence and WCAG: what Atlassian covers, and what is yours
When someone asks “is our Confluence accessible?”, they are usually asking two different questions at once. Separating them is the first useful thing you can do.
Two different things get called “Confluence accessibility”
The first is the product: the editor, the navigation, the search box, the dialogs. Whether a keyboard user can reach the page tree, whether the rich text editor announces itself properly to a screen reader. That is Atlassian's engineering work, tracked in their public accessibility backlog, and described in the VPAT they publish for Confluence Cloud. You cannot fix it and you are not expected to.
The second is the content: the twelve thousand pages your teams wrote. Whether the screenshots have alt text. Whether headings run H2, H3, H3 or jump to H5 because someone liked the font size. Whether the release table has a header row. Whether the grey caption text has enough contrast. None of that is in Atlassian's VPAT, because none of it is Atlassian's content.
Why the distinction decides who has a problem
A procurement questionnaire asks for a VPAT and you send Atlassian's. That answers the product question. But an accessibility complaint, an audit, or a Title II compliance review looks at what a person actually encounters — and what they encounter is a page. If that page is a wall of images with no alt text, the conformance claim fails on the content, regardless of how good the surrounding product is.
This is the uncomfortable part: the product half is improving on someone else's roadmap, and the content half is entirely yours, entirely unmeasured, and growing every day.
What actually fails, in practice
Across real documentation, the same handful of failures account for most of the problem:
- Images with no alt text (WCAG 1.1.1, level A). Pasting a screenshot into Confluence does not prompt for a description, so almost nobody adds one.
- Bold text used as a heading (1.3.1, level A). It looks like a heading and is not one, so it never appears in the heading list a screen-reader user navigates by — which for a long page is the difference between usable and unusable.
- Skipped heading levels (1.3.1, level A). H2 to H4 reads as a missing section.
- Tables without a header row (1.3.1, level A). Every cell is then read without the column it belongs to.
- Link text that says “click here” (2.4.4, level A). Screen-reader users often pull up a list of every link on a page; a list of “click here” is useless.
- Low-contrast coloured text (1.4.3, level AA). Usually a grey chosen to look soft, at around 2.8:1 where 4.5:1 is required.
Every one of these is mechanical. They can be found by a machine and fixed by the person who wrote the page in under a minute each. The difficulty is never the individual fix — it is knowing which of your twelve thousand pages have them.
What a tool can and cannot decide
Be careful with any product that promises conformance. Automated checking settles the mechanical criteria: is there alt text, does the heading sequence hold, does this colour pair reach the required ratio. It cannot settle whether the alt text is a good description, whether the reading order matches the meaning, or whether a video's captions are accurate. Roughly a third of WCAG criteria need a person.
The honest framing is: automate the two thirds that are mechanical, so the human review you pay for is spent on the third that actually needs judgement.
A reasonable order of work
- Establish where you stand. Scan your largest public-facing space and get a number.
- Fix by pattern, not by page. If 400 pages fail on alt text and 30 fail on contrast, the alt text campaign is the whole project.
- Put a check in the authoring flow, so today's pages stop adding to tomorrow's backlog.
- Re-measure on a schedule, and keep the dated evidence.
- Send the remaining judgement calls to a human reviewer.