What a contrast checker can and can’t see
Run a document through a contrast tool and you get a clear, helpful answer to one question: is there enough visual difference between the text and its background for someone with low vision or colour blindness to read it comfortably? That matters, and we would never skip it.
What the tool can’t tell you is how the document behaves for someone who isn’t looking at it at all. A screen reader — software like NVDA or JAWS — turns a PDF into speech or braille, working through the content in a set order. If that order is wrong, or the structure underneath is missing, the document can look perfect on screen and still be confusing — or unusable — for the person relying on assistive technology. That underlying structure is where most of the real work happens, and it’s the part accessibility standards such as WCAG are really concerned with.
Accessibility lives in the structure
When a screen reader opens a PDF, colour isn’t what it meets first. It meets the order the content is read in, whether headings are announced as headings, whether an image is described, and whether a table still makes sense read one cell at a time. None of that shows up in a contrast test, because none of it is about how the page looks.
It’s the same idea as a well-built website: the polished front end only works because of the structure holding it together. Documents are no different — and much of that structure is invisible on the page, which is exactly why it gets missed.
What we build in when we set up an accessible PDF
Here is the checklist we work through. Some of these are invisible to a sighted reader, which is precisely why they matter:
- Correct reading order — the order a screen reader announces content in, which often isn’t the same as where things physically sit on the page.
- Document tags and structure — the hidden framework that tells assistive technology what each element is: a heading, a paragraph, a list, an image.
- Articles — the main tool we use to control reading order. In InDesign, the Articles panel lets us drag text, images and graphics into a deliberate sequence for screen readers, regardless of where they sit physically on the page.
- Bookmarks — a navigable outline so someone can jump straight to the section they need, especially valuable in longer reports.
- Layers — the Layers panel controls the physical, front-to-back stacking of the design. We make sure that stacking order lines up with the Articles panel, so it reinforces the reading order rather than confusing the screen reader.
- Interactive table of contents — a contents list where each entry is a working link to the right place in the document.
- Correctly styled headings, paragraphs and lists — we tag every heading, paragraph and list correctly so a screen reader can tell them apart and announce them. Headings are read out with their level — for example “Heading level 1” — which is what lets people navigate a document by structure rather than working through it line by line.
- Table accessibility — identifying header rows and columns so that when a cell is read aloud, the reader knows exactly where it belongs.
- Document title and author — meaningful document properties, so it’s announced clearly rather than as a filename full of underscores.
- Alt text — short, useful descriptions of images and charts, with purely decorative images marked to be skipped rather than read out.
- Translated accessibility elements for Welsh documents — the behind-the-scenes elements working in Welsh too, not just the visible text (more on this below).
- Proofing and fixing accessibility errors — checking the finished document with tools and by how it actually behaves, then fixing what needs fixing. Automated checkers catch some issues, but not all.
Why Welsh documents need a little extra care
You can see why a single pass through a contrast checker was never going to cover all of this. Accessibility is less like a final inspection and more like good construction: designed in from the beginning, element by element, and verified at the end. Done that way, the result is a document that works well for everyone — including the people who need it most.
And if your current documents don’t tick every box on this list, that’s completely normal. Most documents don’t, because a lot of this is genuinely specialist work. The good news is that it can all be added, and existing documents can usually be remediated rather than rebuilt from scratch.
Built, not just checked
You can see why a single pass through a contrast checker was never going to cover all of this. Accessibility is less like a final inspection and more like good construction: designed in from the beginning, element by element, and verified at the end. Done that way, the result is a document that works well for everyone — including the people who need it most.
And if your current documents don’t tick every box on this list, that’s completely normal. Most documents don’t, because a lot of this is genuinely specialist work. The good news is that it can all be added, and existing documents can usually be remediated rather than rebuilt from scratch.
