PDF, Accessibility, How-ToHow to Make PDFs Accessible and Screen Reader Friendly

By: Robert Soares     |     Feb 15, 2026

Most PDFs Are Broken for Screen Reader Users

Here's something uncomfortable. That PDF you spent three weeks designing, the one with perfect typography and on-brand colors? A blind person can't read it. Neither can someone with low vision using a screen reader. Neither can someone who relies on keyboard navigation because of a motor disability.

The screen reader opens your file and gets chaos. It reads the sidebar before the headline. It skips the table entirely. It announces your decorative swoosh graphic as "image image image" three times. The reading order jumps from page footer to second column to first column because that's the order the design software happened to export objects in.

This isn't a rare problem. The WebAIM Million report consistently finds that PDF accessibility failures are among the most common issues on the web. And the World Health Organization estimates over 2.2 billion people globally have some form of vision impairment. That's not a niche audience.

The good news is that fixing this isn't rocket science. It's tedious, yes. But the individual steps are straightforward, and once you know what to look for, you can build accessible PDFs from the start instead of retrofitting them later.

What Makes a PDF Accessible?

Accessible PDFs have four things that inaccessible ones don't:

1. Tags. Hidden labels that tell assistive technology what each element is. "This is a heading." "This is a paragraph." "This is a table with 4 columns." Without tags, a screen reader just sees a flat stream of characters with no structure.

2. Reading order. The sequence in which content should be read. Visual layout doesn't determine this automatically. A two-column design might look obvious to sighted readers, but a screen reader needs to be told: read the left column first, top to bottom, then the right column.

3. Alt text. Descriptions of images for people who can't see them. Not "image1.jpg." Not "photo." An actual description of what the image shows and why it matters in context.

4. Proper fonts and contrast. Text that can be selected and searched, not text baked into images. Colors with enough contrast to be readable by people with low vision.

That's the whole list. Four things. But each one has nuances that trip people up.

Tags: The Foundation of Everything

Tags are the single most important piece of PDF accessibility. Without them, nothing else works right.

Think of tags as a hidden table of contents for assistive technology. They define the document's structure: headings, paragraphs, lists, tables, figures, links. A screen reader uses tags to let users navigate by heading, skip to the next section, or jump between table cells.

How to Add Tags

If you're creating in Microsoft Word or Google Docs:

Good news. Use the built-in heading styles (Heading 1, Heading 2, etc.) and list formatting. When you export to PDF, the tags carry over automatically. This is by far the easiest path to an accessible PDF. Don't format headings by just making text bigger and bold. Use the actual heading styles.

If you're creating in Adobe InDesign:

InDesign has an Articles panel and a Tags panel. Map your text frames and image frames to the correct PDF tags before export. Under Export Options, check "Create Tagged PDF." InDesign gives you the most control, but it also requires the most manual setup.

If you're creating in Canva, Figma, or similar design tools:

This is where it gets frustrating. Most design tools export flat PDFs with no meaningful tag structure. You'll need to add tags after export using Adobe Acrobat Pro or a dedicated remediation tool like CommonLook or axesPDF.

If you have an existing untagged PDF:

Open it in Adobe Acrobat Pro. Go to Accessibility > Autotag Document. Acrobat will guess at the structure. It's a decent starting point, but you'll need to review and fix the results manually. Auto-tagging gets headings wrong roughly half the time, especially in multi-column layouts.

Common Tagging Mistakes

• Using <P> (paragraph) tags for everything, including headings. Screen reader users navigate by heading. If nothing is tagged as a heading, they have to listen to the entire document linearly.
• Skipping heading levels. Going from H1 to H3 without an H2 confuses the document hierarchy.
• Tagging decorative elements as figures. A background gradient or a divider line doesn't need a tag. Mark those as artifacts so screen readers skip them.

Why Does Your Document Read Backwards?

This is the one that catches people off guard because the problem is invisible.

Open any multi-column PDF in a screen reader and there's a good chance it reads content in the wrong order. The left column's headline, then the right column's headline, then back to the left column's body text. Or worse: footer, sidebar, header, main content.

The reading order in a PDF is determined by the order objects were placed on the page in the authoring tool, not by their visual position. If you drew the sidebar first and the main content second, that's the order assistive technology will read them.

How to Fix Reading Order

In Adobe Acrobat Pro:

Open the Reading Order panel (Accessibility > Reading Order). You'll see numbered boxes overlaid on your content. Each number represents the reading sequence. Drag them into the correct order. It's manual and tedious for long documents, but it's the only way to be sure.

In your authoring tool (before export):

In Word, reading order follows the document's linear flow, so it's usually correct. In InDesign, use the Articles panel to define the reading sequence explicitly. In PowerPoint, use the Selection Pane to reorder objects on each slide.

Quick test: Select all text in the PDF (Ctrl+A / Cmd+A) and paste it into a text editor. If the text appears in a logical reading order, you're probably fine. If it's scrambled, your reading order needs work.

How Do You Describe Images That Matter?

Alt text tells screen reader users what an image shows. It seems simple. It is simple in concept, but people write terrible alt text all the time.

Writing Good Alt Text

Bad alt text: "image" or "photo" or "IMG_4782.jpg"

Mediocre alt text: "Bar chart"

Good alt text: "Bar chart showing quarterly revenue growth from $2.1M in Q1 to $3.8M in Q4 2025, with the largest jump occurring between Q2 and Q3."

The goal is to convey the same information a sighted person would get from looking at the image. For a chart, that means the data and the trend. For a photo of your team, that means who's in it and the context. For a product image, that means what the product looks like and any key details.

When to Skip Alt Text

Decorative images should be marked as artifacts, not given empty alt text. Background patterns, divider lines, purely ornamental graphics. If an image doesn't convey information, tagging it as an artifact tells screen readers to ignore it entirely. That's better than empty alt text, which some screen readers still announce as "image."

The W3C WAI images tutorial is the best reference for deciding which images need descriptions and which don't.

Fonts, Contrast, and Text as Text

Real Text vs. Image Text

Text in a PDF should be actual, selectable text. Not text rendered as part of an image. Screen readers can't read text inside images unless you add alt text for the entire image, which isn't the same thing.

This comes up constantly with:

• Infographics where all the text is baked into the graphic
• Scanned documents that haven't been OCR'd
• Screenshots used in place of formatted text
• Headers and logos with stylized text

If text needs to be read, it needs to be real text. Save the image text for purely decorative purposes.

Font Choice

Some fonts are genuinely harder for people with dyslexia or low vision to read. Thin weights, decorative serifs, and fonts with ambiguous characters (where the lowercase L looks identical to the uppercase I) cause real problems.

Stick with well-designed body fonts. Arial, Verdana, Georgia, and similar workhorses exist for a reason. You don't need to use them for headings and display text, but body copy should prioritize readability over style.

Color Contrast

The WCAG 2.2 guidelines require a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Light gray text on a white background fails this. So does that popular trend of medium-blue text on a light-blue background.

Use a contrast checker. WebAIM's contrast checker is free and takes five seconds. Plug in your text color and background color, and it tells you whether you pass.

Testing with Screen Readers

Automated checkers catch structural problems. But the only way to know if your PDF actually works is to listen to it with a screen reader.

Free Screen Readers to Test With

• NVDA (Windows) - Free, open source. The most popular free screen reader. Download from NVAccess.
• VoiceOver (Mac/iOS) - Built into every Mac and iPhone. Activate with Cmd+F5 on Mac or triple-click the Home button on iPhone.
• Narrator (Windows) - Built into Windows. Press Win+Ctrl+Enter to start.

What to Listen For

Open your PDF in a screen reader and check:

1. Does it announce the document title? If it says the filename instead, you need to set the title in document properties.
2. Can you navigate by heading? Press H in NVDA or use the rotor in VoiceOver to jump between headings. If nothing happens, your headings aren't tagged.
3. Is the reading order logical? Let it read through the first few pages. Does content follow a sensible sequence?
4. Are images described? When the screen reader reaches an image, does it read useful alt text or just "image"?
5. Are tables navigable? Can you move between cells with arrow keys? Does it announce column and row headers?

This testing takes 10-15 minutes for a short document. It's the step most people skip, and it's the step that matters most.

Karl Groves, a well-known accessibility consultant, has written extensively about the gap between automated testing and real-world usability: automated tools catch about 30-40% of accessibility issues. The rest require human judgment. A PDF can pass every automated check and still be unusable if the reading order makes no sense or the alt text is technically present but completely unhelpful.

How Does This Apply to Flipbooks?

If you're converting a PDF to a flipbook, the source PDF's accessibility carries through to the digital version. A well-tagged PDF with proper reading order and alt text produces a more accessible flipbook. A flat, untagged PDF produces a flipbook that's just as inaccessible as the original.

So do the work on the PDF first. Then convert. The PDF tools guide covers the full range of what you can do with PDFs before and after you turn them into something interactive.

A Realistic Starting Point

If you've never thought about PDF accessibility before, don't try to retrofit every document you've ever made. Start with the next one.

1. Use heading styles in your authoring tool. Takes zero extra time.
2. Add alt text to meaningful images as you place them. Takes 30 seconds each.
3. Check the reading order before you export. Takes 5 minutes.
4. Run the Acrobat accessibility checker on the exported PDF. Takes 2 minutes.
5. Listen to the first page with a screen reader. Takes 3 minutes.

That's it for a first pass. You'll catch the big issues. Over time, it becomes habit and stops feeling like extra work. The people who need these accommodations to use your documents will notice the difference immediately.