Most research PDFs look fine. Clean layout, clear headings, well-designed charts. And most of them would fail a basic accessibility check.
Not because anyone made a careless decision, but because the tools used to create them – InDesign, Word, PowerPoint – don’t produce accessible PDFs by default. Accessibility has to be built in deliberately. And in most research teams, it isn’t.
This guide explains what accessible PDFs actually require, where the process most commonly fails, and how to build documents that meet WCAG 2.2 standards without making every export a manual exercise.
Why PDFs are the biggest accessibility risk in research publishing
Research organisations publish a lot of PDFs. Reports, briefings, consultation responses, grant outputs. Under the Public Sector Bodies Accessibility Regulations 2018, all of these must meet accessibility standards if they’re publicly available and produced after September 2018. Pre-existing PDFs are technically exempt unless substantially revised, but in practice, most teams are producing new content constantly.
The problem is structural. PDFs were designed for print fidelity – to look the same everywhere. Screen readers and assistive technologies don’t need it to look the same. They need to understand it. And a PDF that hasn’t been built with semantic structure is essentially unreadable to anyone using assistive technology.
What an accessible PDF actually needs
Accessibility in PDFs is not about visual appearance. It’s about whether the document’s structure can be read, navigated and understood by assistive technologies. That means six things need to be right.
Tagged semantic structure
Every heading, paragraph, list, table and figure needs a PDF tag that tells assistive technologies what it is. Without tags, a screen reader encounters a flat stream of text with no hierarchy, no navigation and no context. A visually clear heading is invisible to a screen reader if it’s just styled text rather than a tagged heading element.
Logical reading order
In multi-column layouts, sidebars and complex page designs, the visual reading order and the underlying document order often diverge. Assistive technologies follow the document order, not what the eye sees. If a pull quote appears before the paragraph it relates to in the tag tree, a screen reader will read it at the wrong point.
Alt text for images, charts and figures
Every image, chart, infographic and decorative element needs to be handled correctly. Meaningful visuals need descriptive alt text. Decorative images should be marked as such so screen readers skip them. For charts, alt text must convey the data, not just the visual (“Bar chart showing…” is not sufficient – the data needs to be communicated).
Sufficient colour contrast
Body text needs a contrast ratio of at least 4.5:1 against its background. Large text (18pt+ regular or 14pt+ bold) needs 3:1. These requirements apply to text in charts and diagrams too, not just body copy. Article 4 covers data visualisation contrast in detail.
Document metadata and title
An accessible PDF has a document title set in the metadata, not just in the visual layout. It also has a language set so screen readers use the correct pronunciation rules. These are small things that are frequently overlooked and consistently flagged in accessibility audits.
Accessible tables
Tables need header rows marked as headers so assistive technologies can identify which column or row a cell belongs to. Merged cells and complex table structures cause particular problems and should be simplified wherever possible.
Where the process breaks down
The most common failure point is export. A document is designed in InDesign or laid out in Word, and the PDF is generated at the end. At that point, the accessibility decisions have already been made – or not made.
InDesign can produce well-tagged, accessible PDFs, but only if the document has been set up correctly: paragraph styles applied consistently, reading order defined in the Articles panel, alt text added to every image, export settings configured for accessibility. Most InDesign documents used in research teams are not set up this way, because the template was never built with accessibility in mind.
Word is more forgiving – if you use built-in heading styles and the Accessibility Checker before export, you can produce a reasonably accessible PDF. But “reasonably accessible” still requires deliberate choices that most people don’t know to make.
The root cause is almost always the same as we describe in Article 1: accessibility was never built into the template infrastructure. It’s being addressed at the end of every project rather than resolved once at system level.
Fixing it at system level, not project level
The most effective intervention isn’t training every researcher to check their PDFs. It’s building templates that make accessible output the default.
That means report templates with pre-defined heading styles that map to correct PDF tags. Chart templates with accessible colour palettes. InDesign documents with reading order already defined. A consistent export process with accessibility settings saved.
When the template does the work, the researcher doesn’t need to remember. And when a new report is produced, it’s accessible by default rather than accessible by accident. We cover how this connects to brand system design in Article 6.
A practical checklist before you export
Before exporting any research PDF, work through these:
- Heading styles applied using paragraph styles, not manual formatting
- Reading order checked and correct in multi-column or complex layouts
- Alt text added to all meaningful images and charts
- Decorative images marked as background or artefact
- Colour contrast checked against WCAG 2.2 AA minimums
- Document title and language set in metadata
- Tables use header rows, not just bold text
- Accessibility Checker run (InDesign, Word or Acrobat) and issues resolved
If this list needs to happen from scratch on every document, the template isn’t doing its job.
Good design makes research clearer. Accessible design makes it inclusive.
For publicly funded research organisations, accessible PDFs are a compliance requirement. But beyond compliance, they’re a basic quality standard. A report that a policymaker can’t navigate with a screen reader, or that a visually impaired stakeholder can’t read, has failed at its primary purpose: communicating research. Talk to us about redesigning your report templates.