Accessible PDFs: what to check and how to fix them

A PDF can look perfect and still be unreadable to a screen reader. The page you see is one layer. The other is a hidden structure of tags that labels each piece of content as a heading, paragraph, list item, table cell or figure, in reading order. WebAIM puts the consequence plainly: an untagged PDF would not be considered "accessible."

This guide lists what to check in a PDF, how each check maps to WCAG and to the checks in our free PDF accessibility checker, what PDF/UA adds, how to fix problems at the source in Word and InDesign, and how to repair a PDF that has no source file.

Do you need a PDF at all?

Section508.gov, the U.S. government's guidance site, says PDFs are often not the most accessible or mobile-friendly option, and that federal policy requires agencies to prioritize HTML and use PDFs only when necessary (Create Accessible PDFs). That is a rule for federal agencies, but the reasoning carries over: a web page reflows, scales and updates more easily than a file. Keep PDFs for what needs a fixed layout, such as forms, print material and records, and give each one the same care as a page.

Does WCAG apply to PDFs?

W3C publishes PDF techniques that show how WCAG success criteria are met in a PDF: its index of techniques for WCAG 2.2 lists 23 of them (PDF1 to PDF23). They cover alt text, bookmarks, tab order, decorative images, tables, headings, lists, language, titles, links, forms and OCR for scanned documents. The table below names the technique for each check.

Laws reach PDFs too. Section508.gov publishes guidance on making PDFs meet the U.S. federal standard, and our page on Section 508 and WCAG explains how documents fit in. The Department of Justice's fact sheet on the ADA Title II web rule includes PDFs among its examples of documents. Its exception for older documents does not cover documents currently used to apply for, access or participate in a government's services, even if they were posted before the compliance date; our ADA Title II deadline guide tracks the dates. Which WCAG version applies depends on the law: see which WCAG version the law requires. This guide is not legal advice.

What to check in an accessible PDF

Each row is something a screen reader user depends on. The last column says what our PDF checker does with it, so you know which items still need a person.

How to fix each problem

Real text, not a picture of a page

W3C's technique PDF7 describes running OCR on a scanned PDF to provide actual text, because a document whose content is images is inherently inaccessible. OCR output still needs tags, a language and a proofread. If you have the original Word or InDesign file, export from that again: the structure comes with it. A quick test is to try to select a word with the mouse, or copy a sentence and paste it into a text editor. The FAQ on our checker explains how a file can fool the check in each direction.

Tags and reading order

Tags come from the source file (see the Word and InDesign steps below). Then check the order: the tab order must reflect the logical order of the document (PDF3), and reading order comes mainly from the order of the tags. Only a screen reader tells you whether the order is right. A simplified tag tree looks like this:

Document
  H1       Annual report
  P        Opening paragraph
  Figure   (Alt: Bar chart of sales by quarter)
  Table
    TR
      TH   Quarter
      TH   Sales
  L        (a list)
    LI     First item

Language and title

PDF16 sets the document's default language in the file, normally through the authoring tool. In Acrobat Pro, W3C describes File, Properties, Advanced, then the Language list under Reading Options. For the title, PDF18 sets the Title entry and turns on the DisplayDocTitle flag so the title bar shows the title, not the file name; in Acrobat Pro that is Initial View, with Show set to Document Title. Give the file a title that says what it is, such as "Annual report 2026", not a default like "Microsoft Word - report.docx".

Alt text and decorative images

A figure that carries information needs a text alternative that conveys the same meaning as the image (PDF1). Purely decorative images are marked as artifacts so screen readers skip them (PDF4). The rules are the ones for web images: see our alt text guide, alt text examples, decorative images and alt text for charts. A figure described as "image" passes our checker and fails the reader, so check the words yourself.

Headings, lists and tables

Use real heading styles, in order, rather than large bold text. Microsoft's Word guidance says to organize headings in logical order and not skip levels. Use list styles for lists (PDF21) and give each data table a header row (PDF6); in Word that is the Design tab, Table Styles Options group, then Header row. Our heading structure guide explains why this helps on the web as well.

Links

A link should say where it goes, in the PDF and on the page that points to it. A bare URL or "click here" tells a screen reader user nothing in a list of links. See WCAG 2.4.4 Link Purpose, and paste the HTML of the page that links to the file into the link text checker.

Bookmarks

PDF2 treats bookmarks as an advisory technique for 2.4.5 Multiple Ways. Word can build them from headings when you export (Options, then Create bookmarks using Headings), and Adobe lists the table of contents and bookmarks among the navigation elements that help assistive technologies in an InDesign PDF. A short document does not need them; a long one is hard to move around in without them.

Forms

A form field is announced by its tooltip, so each field needs one that says what to enter (PDF12). Set the tab order to follow the document structure (PDF3). W3C also has techniques for indicating required form controls (PDF5) and for indicating when input falls outside the required format or values (PDF22). Our checker reads tooltips where it can, and it cannot read the contents of XFA forms. Test a form by tabbing through it with the keyboard; see the keyboard accessibility test.

Color, contrast and security settings

WCAG's contrast requirements apply to what is on the PDF page, and our checker does not read colors. Use the contrast checker for a color pair, or take a screenshot of a page and use the image contrast checker for text over images; the color contrast guide and text over images guide explain the ratios. If a file's security settings block text extraction, remove the restriction or keep the permission that lets assistive technology read the text.

PDF/UA (ISO 14289): what it is and where it fits

PDF/UA, short for PDF for Universal Accessibility, is the ISO standard for accessible PDF. It is a technical standard about the file: it states the technical features an accessible PDF must have, built on the Tagged PDF feature. The PDF Association, which maintains the PDF/UA resources, describes it as a companion to ISO 32000 that provides a means of making PDF files that conform to WCAG and can be used together with WCAG 2.x.

Two limits matter. First, the PDF Association says that by itself conformity to PDF/UA does not necessarily ensure the accessibility of a document's content. Its examples of what the standard does not cover include color and contrast, scripts that can produce inaccessible results, and content that is inaccessible to people with certain cognitive impairments. Second, PDF/UA does not describe how to achieve conformance or how to convert a file that does not conform. The PDF Association makes the standards available at no cost as part of its PDF/UA bundle.

Where a law names a technical standard for web content, it is generally WCAG or one built on it (see which WCAG version the law requires). PDF/UA is a way to build and test the file, not a replacement for the WCAG criteria, so read the exact wording of any law or contract that applies. Formal PDF/UA conformance testing needs a dedicated validator; our checker is a quick first look, not a PDF/UA test.

Fix it at the source: Word, InDesign and Acrobat

Microsoft says the fastest and easiest way to make sure your PDF is accessible is to run the Accessibility Checker before you save the document as a PDF, because Microsoft 365 uses the result to create the tags. Our checker's FAQ makes the same point in practice: exporting again with tagging switched on is far less work than repairing tags afterward.

Word

1. Apply the built-in heading styles in order, and give tables a header row. See Microsoft's guide to making Word documents accessible, which also covers alt text for images.
2. Run the Accessibility Checker and fix what it reports.
3. On Windows, choose File, then Save As (or Save a Copy), pick PDF, then More options, Options, and make sure "Document structure tags for accessibility" is selected. In the same dialog, "Create bookmarks using" with Headings adds bookmarks, and "Document properties" includes the document's properties in the PDF (Microsoft: save or convert to PDF).
4. On a Mac, choose PDF as the file format and "Best for electronic distribution and accessibility (uses Microsoft online service)". Microsoft states that this sends the document to a Microsoft online service for conversion. In Word for the web, use File, Save As, Download as PDF. All three routes are on Microsoft's page Create accessible PDFs.

InDesign

1. Map paragraph styles to PDF tags: in Paragraph Style Options, open Export Tagging and choose a Tag under PDF (Adobe: map styles to export tags).
2. Set the reading order in the Articles panel: add the page items to an article, drag them into order and choose "Use for Tagging Order in Tagged PDF" from the panel menu (Adobe: set reading order).
3. Add alt text with Object, then Object Export Options, on the Alt Text tab. The Tagged PDF tab lets you choose how the object is tagged (Adobe: object export options).
4. Export with File, Export, Adobe PDF (Print), with Create Tagged PDF selected, then open the file in Acrobat and look at the Tags panel to verify the tags (Adobe: use tags for accessible PDFs). Adobe's overview notes that the title and description from the document's metadata transfer to the exported PDF (Adobe: accessible PDFs).

Acrobat Pro and other tools

Acrobat Pro also has a built-in accessibility check and a Tags panel, and W3C's techniques describe repairs in it. Other authoring tools differ. Check whether the export option produces tags, then test the result as the "Test the result" section below describes.

No source file? Repair the PDF

Many PDFs arrive without the Word or InDesign file behind them. For that case W3C's techniques describe repairs in Adobe Acrobat Pro. Treat them as the fallback: W3C calls structuring the document in the authoring tool the simplest way to get a correct reading order (PDF3) and the easiest way to create lists (PDF21), and our checker's FAQ says exporting again is far less work than repairing tags afterward. When there is no source file, work in this order:

1. Run OCR first if the file is a scan. PDF7 says that when authors do not have the source file, scanned images of text can be converted with optical character recognition, after which Acrobat Pro can be used to create accessible text. Correct the words Acrobat lists as OCR suspects, then add tags. The technique notes that Acrobat Pro may add tags automatically when the file goes through OCR, and that the Reading Order tool and the Tags panel are needed to tag the content properly.
2. Fix tags and reading order. Use Acrobat Pro's Reading Order tool and the Tags panel. PDF21 describes both for repairing lists, and PDF3 says pages with complex layouts may not convert to tagged PDF in the correct reading order and must then be corrected with repair tools such as Acrobat Pro. The tab order must reflect the logical order of the document.
3. Fix tables. PDF20 uses the Table Editor in Acrobat Pro's Reading Order tool to repair tables, for example by changing header cells that were tagged as data cells and by correcting row spans.
4. Set the title and language. The Acrobat Pro steps for the title (PDF18) and the document language (PDF16) are in the language and title section above.
5. Test again. Run the checker, copy some text and listen to the file, as described next.

Test the result

1. Run the PDF checker

   The PDF accessibility checker reads your file inside your browser and never uploads it. It takes files up to 100 MB, and its page-level checks cover the first 200 pages. Each finding says what it means for a screen reader user and how to fix it in Word, InDesign or Acrobat where we can say so accurately.

2. Select and copy some text

   If you cannot select a word, a screen reader cannot read it either. Paste a copied sentence into a text editor to check that real words come out.

3. Listen to it

   Open the file with a screen reader and compare what you hear with what the page shows. NVDA is free. Our guide to testing website accessibility covers screen reader basics.

4. Tab through links and fields

   Focus should move in the order of the document and every field should be announced with its name.

5. Check contrast and the words of the alt text

   Both are outside what a structural check can see.

6. Re-export instead of patching

   When something is wrong, fix the source file and export again, then repeat the checks. If there is no source file, repair the PDF as described above and test again.

People usually find a PDF through a web page. The free scan checks the pages that link to your documents for the problems a machine can find, and the website accessibility audit guide explains what a fuller evaluation adds. If you publish an accessibility conformance report as a PDF, it has to be accessible too: see VPAT and ACR.