A PDF made from a messy document stays messy. Most accessibility work happens in the file you export from, so fix the structure there and then confirm the export kept it.

Decide whether you need a PDF at all

If readers only need to read the content, a normal web page is often the simpler thing to keep accessible. A PDF makes sense when people need a fixed layout to print, sign or keep. If you do offer one, publish the same content as an HTML page too, and link the PDF from it. That is our suggested practice, not a requirement.

Say what the file is on the link itself, for example “Reading log template (PDF)”, so nobody opens a download by surprise.

Fix the source document first

W3C’s PDF techniques describe adding headings, image alternatives and other properties with authoring tools such as Microsoft Word, OpenOffice or Adobe Acrobat Pro. In practice that means using real heading styles instead of bold, enlarged text, and writing the image descriptions before you export.

Our rule: if the source document has no headings and the images have no descriptions, do not expect the export to invent them.

Check four properties

The same judgment applies as on a web page: decorative images do not need a description. See the alt text guide for how to decide.

  • Title: W3C’s technique PDF18 sets the document title in the file’s properties and turns on the option that shows it in the title bar, so a reader can tell which document is open.
  • Language: technique PDF16 sets the document’s default language so screen readers can apply the right pronunciation rules.
  • Headings: technique PDF9 marks headings as heading tags, which lets assistive technology users open a list of headings and jump to a section.
  • Images: technique PDF1 gives each meaningful image a text alternative that conveys the same meaning as the image, including any important words in it, rather than describing how it looks.

A fictional example

Imagine a two-page “weekly reading log” template. In the draft, the section names are bold 14-point text, there is a logo with no description and the file is called final2.pdf. A better version uses Heading 1 and Heading 2 styles, marks the logo as decorative, gives the sample chart a one-sentence description, sets the title to “Weekly reading log template” and the language to English, and is saved as weekly-reading-log-template.pdf.

The scenario is invented for illustration. The visible page looks nearly identical; the difference is what a screen reader or a heading list can find.

Test the exported file, not the source

Open the PDF you will actually publish. Check its document properties for the title and language, and look for a headings or tags view in your PDF viewer or editor. W3C lists screen reader testing, PDF editor inspection and accessibility API tools as ways to verify these techniques. If you can try a screen reader, listen to the first page.

Also confirm that the text can be selected. If it cannot, the page may be a scanned picture, which is a bigger problem than any missing tag.

What this checklist leaves out

These four checks are a starting point drawn from individual W3C techniques; they are not a full conformance test. Tables, forms, reading order and colour contrast also matter, and a PDF with complex content may need review by someone who specialises in accessibility. If you cannot make a file accessible, offer the HTML version as the main way to read it.

Sources & context

Sources checked on 11 October 2026. Worked examples are fictional; the suggested checklists are editorial advice.

Use this next

Keep exploring

Use the free tools