Documents

PDF Accessibility Checklist: How to Create Accessible PDFs That People Can Actually Use

A practical PDF accessibility checklist covering tags, reading order, headings, links, tables, alt text, forms, metadata, export settings, and testing.

By A11y Lens Team · Updated 2026-07-24 · 10 min read

PDF accessibility is not only about passing an automated checker. A PDF can show a green result and still be painful to use if the reading order is confusing, headings are fake, tables have no headers, or form fields are not named clearly.

The goal is simple: a person using a screen reader, keyboard, magnification, reflow, or high contrast settings should be able to understand and complete the document without guessing.

This checklist is written for teams that publish reports, brochures, policies, statements, invoices, forms, guides, and public documents.

Start with the source file

The most accessible PDF usually begins before the PDF exists. If the document starts in Word, PowerPoint, InDesign, Google Docs, or another authoring tool, fix the source first.

Why this matters:

  • Fixing structure in the source file is faster than repairing tags later.
  • Re-exporting a corrected source is cleaner than patching a broken PDF.
  • Teams can reuse the accessible source for future updates.
  • Accessibility survives better when it is part of the normal publishing workflow.

If the content can be a web page instead of a PDF, choose HTML. HTML is usually easier to make responsive, searchable, translatable, and usable on mobile.

Add a document title

Every accessible PDF should have a clear document title. A file name like final_report_v7_fixed.pdf is not enough.

Good document titles include:

  • Annual Accessibility Report 2026
  • Employee Benefits Enrollment Guide
  • Public Meeting Agenda for July 2026
  • Product Safety Notice for Customers

A good title helps screen reader users understand where they are when the file opens. It also improves search snippets, bookmarking, and document management.

Use real tags

PDF tags are the structure that assistive technology reads. Without tags, a PDF may look fine visually but behave like a flat picture or a pile of disconnected text.

Important tag checks:

  • The PDF is tagged.
  • Headings use heading tags, not just bold text.
  • Paragraphs are tagged as paragraphs.
  • Lists are tagged as lists.
  • Tables are tagged as tables.
  • Figures have alt text or are marked decorative.
  • Artifacts such as page numbers, borders, and decorative lines are not read as main content.

If a PDF has no tags, it is usually not accessible.

Check the reading order

Reading order is one of the biggest PDF accessibility problems. Sighted readers can visually jump across columns, sidebars, captions, and callouts. Screen reader users depend on the order exposed by the file.

Review reading order when the document has:

  • Multiple columns
  • Sidebars
  • Infographics
  • Tables
  • Floating images
  • Headers and footers
  • Footnotes
  • Form fields
  • Presentation-style layouts

A practical test is to read the PDF from top to bottom using a screen reader or the reading order tool in your PDF editor. The experience should match the intended meaning, not merely the visual position of boxes on the page.

Build a clear heading structure

Headings are navigation. They let users skim, jump, and understand the outline of the document.

Use headings this way:

  1. Use one clear main title.
  2. Use heading levels in order.
  3. Do not skip from a main heading to a very deep heading level.
  4. Do not use bold paragraphs as fake headings.
  5. Keep headings descriptive, not vague.

Weak heading:

  • Details

Better heading:

  • Eligibility Requirements for New Employees

For long PDFs, headings are not optional decoration. They are the map.

Write useful alt text

Images need text alternatives when they communicate information. Good PDF alt text explains purpose, not every visual detail.

Examples:

  • A decorative divider should be marked decorative.
  • A company logo can use the organization name.
  • A chart should summarize the trend or key data.
  • A product photo should describe the identifying information users need.
  • A screenshot in a tutorial should explain the step being shown.

Avoid alt text such as:

  • image
  • picture
  • graphic
  • screenshot
  • file names like IMG_2048.jpg

If the image contains complex data, include the full explanation in nearby body text or an appendix, not only inside the alt text field.

Make links understandable

PDF links should make sense out of context.

Poor link text:

  • Click here
  • Read more
  • Learn more
  • https://example.com/page?id=889

Better link text:

  • Download the employee accommodation request form
  • Read the public meeting accessibility policy
  • Open the WCAG 2.2 overview

Also check that links are tagged correctly and that the visible link text matches the destination.

Keep tables simple

Tables are accessible when they are real data tables with clear relationships. They become difficult when they are used for visual layout or contain merged cells, nested structures, and missing headers.

Best practices:

  • Use tables only for data.
  • Include column headers.
  • Include row headers when needed.
  • Avoid merged and split cells where possible.
  • Add a short table summary in nearby text for complex data.
  • Do not use empty cells to create spacing.

If the table is too complex to explain quickly, consider splitting it into smaller tables.

Make PDF forms keyboard and screen-reader friendly

PDF forms need more than visible boxes.

Check each field for:

  • A clear accessible name
  • A logical tab order
  • Required fields identified visually and programmatically
  • Helpful instructions
  • Error messages that explain how to fix the problem
  • Checkboxes and radio buttons grouped correctly
  • Submit, reset, and download buttons with clear labels

Test the form without a mouse. If you cannot complete it with the keyboard, the form is not ready.

Set the document language

The document language helps screen readers pronounce content correctly. Set the primary language of the PDF. If the document includes substantial passages in another language, mark those passages where the tool allows it.

This is especially important for public notices, multilingual guides, legal documents, education materials, healthcare forms, and government services.

Export the PDF correctly

Many accessibility problems happen during export.

Before exporting:

  • Run the accessibility checker in the source tool.
  • Use built-in headings and lists.
  • Add alt text before export.
  • Give slides or sections clear titles.
  • Avoid printing to PDF when it removes structure.
  • Use an export option that preserves tags and document properties.

After exporting:

  • Run a PDF accessibility checker.
  • Review tags manually.
  • Check reading order.
  • Test keyboard navigation.
  • Test with a screen reader for important documents.

Automated checks are useful, but they do not understand every human context.

Practical PDF examples and solutions

Here are common real-world PDF problems and how to fix them.

Example 1: Scanned policy PDF

Problem: A team uploads a scanned policy document. It looks readable, but screen readers announce nothing useful because the page is only an image.

Solution:

  1. Run OCR to convert the scan into real text.
  2. Check the OCR output for spelling and reading mistakes.
  3. Add tags for headings, paragraphs, lists, and tables.
  4. Set the document title and language.
  5. Check reading order before publishing.

Better approach: Recreate the policy from the original Word or HTML source when possible. A clean source file usually produces a better accessible PDF than repairing a scan.

Example 2: Annual report with charts

Problem: The report includes revenue charts, but the alt text only says chart.

Solution:

  • Add a short summary near the chart, such as Revenue increased each quarter, with the largest growth between Q3 and Q4.
  • Use alt text that identifies the chart purpose.
  • Include the data table in the document or appendix when the numbers matter.
  • Make sure chart colors are not the only way to distinguish categories.

Practical fix: Put the key insight in normal text before the chart. Then the chart supports the message instead of carrying the entire message alone.

Example 3: Fillable request form

Problem: A PDF accommodation request form has visible fields, but keyboard users tab through them in the wrong order and screen readers announce labels like Text field 12.

Solution:

  1. Rename every field with a clear label, such as Employee name, Email address, or Requested accommodation.
  2. Set the tab order to follow the visual order.
  3. Mark required fields properly.
  4. Add instructions before complex sections.
  5. Test the form using only Tab, Shift+Tab, Space, Enter, and arrow keys.

Good form fields should feel predictable. Users should not have to guess what a blank box means.

Common PDF accessibility mistakes

The most common problems are predictable:

  • Scanned image-only PDFs with no OCR text
  • Missing tags
  • Wrong reading order
  • Fake headings
  • Missing alt text
  • Layout tables used for spacing
  • Untagged form fields
  • Vague link text
  • Low color contrast
  • Document language not set
  • Security settings that block assistive technology

Fixing these issues improves usability for everyone, not only screen reader users.

Practical publishing workflow

Use this workflow before publishing a PDF:

  1. Decide whether HTML would be better.
  2. Build structure in the source document.
  3. Use headings, lists, tables, and links correctly.
  4. Add alt text or mark decorative images.
  5. Run the source accessibility checker.
  6. Export with tags enabled.
  7. Check title, language, metadata, and reading order.
  8. Test keyboard navigation.
  9. Review with a screen reader for important files.
  10. Keep the source file so future updates do not restart from zero.

Related reading

For official guidance, review the Microsoft 365 PDF accessibility documentation and the Adobe PDF accessibility overview. For web content that may be better as HTML, start with our WCAG 2.2 guide.

Final takeaway

Accessible PDFs are not created by a last-minute button click. They come from structured source files, careful export settings, manual review, and real testing.

If a PDF is important enough to publish, it is important enough to make usable.

Your privacy choices

We use essential browser storage to remember your preferences. If advertising or analytics is enabled, you can choose whether to allow those non-essential technologies. Read our Cookie Policy and Privacy Policy.