Skip to content
English
Submit a Support Ticket Sign in
Go To Kinexio Website
  • There are no suggestions because the search field is empty.

CMS: Making your PDFs accessible before you upload them

A quick guide for anyone uploading PDF documents through the CMS.

Why this matters

When someone uses a screen reader, magnifier, or keyboard instead of a mouse, a PDF only works for them if it has been built the right way. A scanned image of a page, or a document with no headings or structure, is effectively invisible to that person — the software has nothing to read out or navigate. 

Making a PDF accessible is mostly about how you create the source document (in Word, Google Docs, InDesign, etc.) before you save it as a PDF. Get the source right and the PDF follows. The good news: the same steps that make a document accessible also make it clearer and easier to read for everyone. 

You don’t need to be a specialist. Working through the checklist below will cover the great majority of what’s needed. 

The quick checklist 

Before you upload a PDF, check that it: 

  • Is made of real, selectable text — not a scan or photo of a page 
  • Uses proper heading styles (Heading 1, Heading 2…) for its structure, not just big bold text
  • Has alt text on every meaningful image, and marks decorative images as decorative
  • Uses real bulleted / numbered lists and real tables (with header rows), not spaces or tabs
  • Has descriptive link text (“Read the parking policy”) rather than “click here” or a raw web address
  • Has a document title and the correct language set in the file’s properties
  • Doesn’t rely on colour alone to make a point, and has enough contrast to be read easily
  • Was saved / exported as a tagged PDF and passed the built-in accessibility checker

Each of these is explained below. 

Step by step 

1. Start with real text, not a scan 

If your PDF is a scan or a photo of a printed page, it’s just a picture — assistive technology can’t read a word of it. Whenever possible, create the document digitally (in Word, Google Docs, etc.) and export to PDF. 

If you only have a scanned copy, run OCR (Optical Character Recognition) on it first to turn the picture into real text. Adobe Acrobat and most scanning tools can do this. A quick test: open the PDF and try to select a sentence with your cursor. If you can highlight the words, it’s real text. If it selects as one big block or not at all, it’s an image and needs OCR. 

2. Use heading styles for structure 

Headings are how a screen-reader user skims a document — they can jump from heading to heading the way a sighted reader scans down a page. But this only works if you use your program’s built-in heading styles (Heading 1 for the title, Heading 2 for sections, and so on). 

Making text big and bold looks like a heading but isn’t one — the software still sees ordinary text. In Word or Google Docs, apply the styles from the Styles menu rather than changing the font by hand. Keep the order logical: don’t skip from Heading 1 straight to Heading 3. 

3. Add alt text to images 

Every image that carries meaning — a chart, a photo, a map, an infographic — needs a short text description (“alt text”) so it can be read aloud. Aim for a sentence that conveys what the image shows and why it’s there (e.g. “Bar chart showing footfall rising 20% from January to June”). 

If an image is purely decorative and adds no information (a background flourish, a divider line), mark it as decorative so it’s skipped rather than described. Most programs let you add alt text or tick a “decorative” box by right-clicking the image. 

Avoid putting important information only inside an image of text — if a poster or notice contains key details, repeat those details as real text as well. 

4. Use real lists and real tables 

Use the built-in bulleted and numbered list buttons rather than typing dashes or numbers by hand — this tells assistive technology “this is a list of items.” 

For tables, use your program’s proper table feature and set a header row so screen readers can announce which column and row a cell belongs to. Keep tables simple: avoid merged cells and nested tables where you can, and don’t use a table just to lay out a page. Tables are for data. 

5. Write descriptive links 

Link text should make sense on its own, because screen-reader users often pull up a list of all the links in a document. “Click here,” “read more,” and pasted web addresses are unhelpful out of context. Instead, describe the destination: “Download the visitor guide (PDF).”

6. Set the document title and language 

In the file’s document properties, give it a meaningful title (this is what’s announced instead of the filename) and set the language (e.g. English) so the screen reader pronounces the words correctly. In Word this is under File → Info / Properties; in most tools it’s in the document or file settings. 

7. Don’t rely on colour alone, and check contrast 

If you use colour to signal something — “items in red are urgent” — add a second cue as well (a label, an icon, bold text), because not everyone can distinguish the colours. And make sure text stands out clearly from its background: dark text on a light background, or vice versa. Very light grey text, or text laid over a busy image, is hard for many people to read. 

8. Save as a tagged PDF and run the checker 

When you export, choose the option that preserves accessibility / document structure — often labelled “tagged PDF” or “best for electronic distribution and accessibility.” This carries all the structure you’ve built (headings, lists, alt text, reading order) into the PDF itself. 

  • In Word: use Save As / Export to PDF and, in the options, tick “Document structure tags for accessibility.” Before that, run Review → Check Accessibility and fix anything it flags.
  • In Google Docs: File → Download → PDF keeps most structure if you’ve used real headings, lists and alt text.
  • In Adobe Acrobat (Pro): use the Accessibility tools / “Prepare for accessibility” check to review tags, reading order and alt text on a finished PDF. 

How to check before you upload 

You don’t have to guess whether a document is accessible — the tools that made it can tell you: 

  • Microsoft Word — Review → Check Accessibility lists issues (missing alt text, bad headings, low contrast) with tips to fix each one. 
  • Adobe Acrobat Pro — the Accessibility Check runs a full report against the PDF standard. 
  • Free option — if you want an independent check, PDF/UA checkers such as the free, open-source veraPDF can validate a finished PDF. 

Aim to clear the checker’s errors before uploading. Warnings are worth a look but don’t always need fixing. 

Common mistakes to avoid 

  • Uploading a scanned document that’s really just an image (no selectable text).

  • Faking headings with big bold text instead of heading styles.

  • Images with no alt text, or key information trapped inside an image.

  • “Click here” links and pasted raw URLs.

  • Using a table to lay out the page, or tables with no header row.

  • Relying on colour alone to convey meaning.

  • Exporting a PDF without tags, so all the structure is lost. 

A note on responsibility 

The CMS gives you the tools and this guidance to publish accessible documents, but the accessibility of a PDF depends on how the source document was authored — which sits with whoever creates the content. If you’re working from a document supplied by someone else, it’s worth checking it against this list (or asking them to) before you upload. 

Where to get help 

If you’re not sure how to fix something the accessibility checker has flagged, or you’ve inherited a document you can’t make accessible, contact support@kinexio.io and we’ll help. 

Related standard: this guidance helps documents meet WCAG 2.2 (notably 1.1.1 Non-text Content, 1.3.1 Info and Relationships, 1.4.3 Contrast, 2.4.4 Link Purpose) and the PDF/UA accessibility standard.