How to make an accessible PDF: five steps that hold up to a screen reader

Most inaccessible PDFs started life as a reasonably accessible Word or InDesign file. The headings were styled as headings. The images had captions. Then someone chose Print, then Save as PDF, and the structure was thrown away on the way out. A screen reader user now gets the document as one long run of text, with no headings to jump between, tables read cell by cell with no idea which column they are in, and the page number announced at the top of every page.

A PDF is accessible when the file carries a hidden layer of structure, called tags, that tells assistive technology what each piece of content is and in what order to read it. Headings are tagged as headings. Tables are tagged as tables, with their header cells marked. Images carry a text alternative. Page furniture like running headers and decorative rules is marked so it is skipped. Most of that structure should come from the source file. Most of the work teams do happens in Acrobat, long after the decisions that caused the problems were made.

Two standards define what “accessible” means for a PDF. WCAG 2.1 AA applies to documents as well as web pages: the W3C publishes specific PDF techniques for it, and clause 10 of EN 301 549, the European standard, applies its criteria to non-web documents. PDF/UA (ISO 14289) is the PDF-specific standard that says how the file itself must be built. PDF/UA-1 was published in 2012 and revised in 2014; PDF/UA-2 followed in 2024 for files built on PDF 2.0. The requirements are no longer theoretical. The US Department of Justice’s ADA Title II rule names PDFs and other documents posted by state and local governments and requires WCAG 2.1 AA, from 26 April 2027 for larger public entities. The European Accessibility Act has been enforceable since 28 June 2025.

The five steps below are in the order the work should happen. Most teams start at step four, which is why the same faults come back in every new document.

1. Build the structure into the source file

Everything a screen reader needs can be expressed in Word, PowerPoint or InDesign, and it survives export far more reliably than anything added afterwards.

• Use real heading styles, in order. Heading 1 for the title, Heading 2 for sections, Heading 3 inside them. Don’t skip levels, and don’t make a heading by setting body text in bold at 18pt. Screen reader users navigate by heading the way sighted readers skim.
• Use the list tools. A bullet typed as a hyphen is just a hyphen. A list built with the list button is announced as a list of five items, so the reader knows how long it is.
• Keep tables for data, and keep them simple. Mark the header row (in Word, “Repeat as header row at the top of each page”), avoid merged and split cells, and never use a table to lay out a page.
• Write alt text for every image that carries meaning, and mark the rest as decorative. For a chart, the alt text should state what the chart shows, and the underlying numbers belong in a table or the text nearby.
• Write links that make sense on their own. “Download the 2026 rate card” tells someone where the link goes. “Click here” doesn’t, and screen reader users often pull up a list of links out of context.
• Check colour and text. Body text needs a contrast ratio of at least 4.5:1 against its background, and large text at least 3:1. Don’t use colour as the only way to convey meaning, and keep real text out of images.
• Set the document language, and mark any passage in a different language.

In InDesign the same rules apply through different controls: map paragraph styles to tags in Export Tagging, add alt text in Object Export Options, and set the reading order with the Articles panel.

This is the step that scales. Put these rules into the template, and every document built from it inherits them.

2. Export a tagged PDF, the right way

The export route decides whether the structure from step one reaches the PDF at all.

• Word on Windows: File, then Save As or Save a Copy, choose PDF, then More options and Options. Tick Document structure tags for accessibility, and set bookmarks to be created from headings.
• Word on Mac: File, then Save As, choose PDF, and select Best for electronic distribution and accessibility. The “Best for printing” option drops the tags and can break links.
• InDesign: export to Adobe PDF and tick Create Tagged PDF. For interactive PDFs, also tick Use Structure for Tab Order.
• Never use Print to PDF. It treats the document as ink on paper and discards the tags.

Scanned documents are a separate problem. A scan is a picture of text, so a screen reader finds nothing to read. Optical character recognition makes the text selectable, but the file still needs every step that follows, and for anything longer than a few pages it is usually faster to rebuild it from a source file.

3. Set the properties that sit outside the content

A few settings live in the file’s properties rather than on the page, and they are easy to forget. In Acrobat Pro they are under File, then Properties.

• Title. Enter a real title in the Description tab. Then, in Initial View, set the window to show the document title. Otherwise the reader hears a file name like “Final_v7_JK_edits.pdf”. PDF/UA requires both.
• Language. Set the document language in the Advanced tab, so a screen reader uses the right voice and pronunciation.
• Bookmarks. For anything longer than a few pages, make sure bookmarks exist and follow the headings. They give every reader a table of contents in the navigation pane.
• Security. If the file is password protected against copying or editing, check that the restriction still allows screen readers to access the text. Acrobat’s checker flags this as the accessibility permission flag.

4. Check and repair the tags and reading order

This is where Acrobat Pro comes in, and where most remediation time goes. The tools are under All tools, then Prepare for accessibility.

• Start with the tag tree. Open the Tags panel (View, Show/Hide, Navigation panes, Tags). If the document has no tags, Automatically tag PDF will create some. Treat that as a first draft. Auto-tagging guesses, and it often guesses wrong on columns, sidebars and tables.
• Confirm the reading order. The order of the tag tree is the order a screen reader reads. Two-column layouts, pull quotes and callout boxes are the usual places it goes wrong. Use Fix reading order to retag regions and drag them into sequence.
• Check every tag type. Headings should be tagged H1 to H6 with no skipped levels. Lists should use the list tags (L for the list, LI for each item). Tables should use Table, TR, TH and TD, and each header cell (TH) should say whether it heads a column or a row.
• Mark page furniture as artifacts. Running headers, footers, page numbers, background shapes and decorative lines should be artifacts, so they are not read out on every page.
• Review alt text. Add alternate text walks through every figure. Check that each description says what the image contributes, and that decorative images are artifacts rather than figures with empty descriptions.
• Fix form fields. Every field needs a tooltip, which is what a screen reader announces as its name, and the tab order should follow the visual order of the form.

Every repair made here lives only in this PDF. The next time someone exports from the source file, it is gone. Whenever you find the same fault twice, fix it in the template as well.

5. Test with a checker, then with a screen reader

Automated checkers are fast and worth running on every file. They also have a hard ceiling.

• Acrobat’s checker. Run Check for accessibility and open the report. Two items always come back as “needs manual check”: logical reading order and colour contrast. Software can’t judge either.
• PAC. The free PDF Accessibility Checker (PAC 2024, now PAC 2026) tests a file against PDF/UA and WCAG, following the Matterhorn Protocol, the PDF Association’s published list of the ways a file can fail PDF/UA. It runs on Windows only; on a Mac, use an online checker such as axesCheck.

Even a clean result only covers what a machine can see. The Matterhorn Protocol lists 136 ways a file can fail PDF/UA, and roughly a third of them can only be judged by a person. No checker can tell whether alt text describes the image, whether a heading describes its section, or whether the reading order makes sense.

So finish with a screen reader. NVDA is free on Windows and works well with Acrobat Reader. Ten minutes is enough to catch the faults that matter most:

1. Let it read the first page aloud from the top. Does it start with the title, in the right language?
2. Press H to jump between headings. Do they appear in a sensible order and describe their sections?
3. Press T to move to a table, then arrow through it. Does it announce the column header for each cell?
4. Listen to each image. Does the description add what the picture adds?
5. Tab through links and form fields. Does each one have a name you would understand without seeing the page?

The pattern behind the fixes

Audit a library of PDFs and the findings run into the hundreds. The causes are usually a handful of decisions repeated in every file: a template with no heading styles, a logo placed without alt text, an export preset that drops the tags, a brand grey that fails contrast. Fix those decisions once, in the template and the export settings, and every document produced afterwards starts out accessible. Fix them one PDF at a time, and the queue never shrinks.

That is the work we do. Our audit checks your documents and digital properties against WCAG 2.1 AA and EN 301 549, groups the findings by cause rather than by file, and turns the fixes into a spec your team builds from. Book the audit to find out where your documents stand.