How to Make a PDF Accessible With Adobe Acrobat

What Makes a PDF Accessible?

Adobe's help page on creating and verifying PDF accessibility names two standards: WCAG and PDF/UA (Universal Access, ISO 14289). Each requirement below maps to a rule in Acrobat's checker:

PDFs are one of several surfaces covered in this guide to digital accessibility, alongside websites, apps, and video.

How to Run the Adobe Accessibility Checker

The checker is part of Acrobat Pro. These steps follow Adobe's help page, last updated February 26, 2026:

• Open the PDF in Acrobat Pro.
• From the global bar in the upper left, select All tools, then View more, then Prepare for accessibility.
• In the left panel, select Check for accessibility.
• In the Accessibility Checker Options dialog, choose the checks to run and select Start Checking.
• Review the issues in the right panel. Select Open accessibility report in the left panel for the full report.

Adobe notes that Prepare for accessibility runs on all PDFs except dynamic forms (XFA documents) and portfolios.

How to Read the Accessibility Report

Each rule gets one of four statuses:

• Passed - the item is accessible.
• Failed - the item did not pass and needs a fix.
• Needs Manual Check - the checker could not decide; verify it yourself.
• Skipped By User - the rule was not selected in the options dialog.

Rules are grouped into Document, Page content, Forms, Alternate text, Tables, Lists, and Headings. Adobe also warns that the check does not separate essential from nonessential content, so some reported issues may not affect readability; review each one before you decide.

Two items always need a person: logical reading order, which Adobe says to verify in the Tags panel, and color contrast, which should meet WCAG 1.4.3. Check text and background pairs in a color contrast checker. Adobe also recommends checking tables manually because table structure can be complex.

How to Fix the Most Common Failures

For any failed rule, select the ellipsis next to it in the checker panel and choose Fix; Acrobat either fixes it or opens the dialog you need. The manual routes for the most common failures, from Adobe's help page:

Adobe also lists a source-side route for tagging: enable tagging in the application that created the document and re-create the PDF, so the headings and structure you set there carry into the file.

Accessibility Markers Inside a Real PDF

To see what Acrobat's Document and Forms rules read, I downloaded the IRS Form W-9 PDF on October 22, 2026 and scanned its internal objects with a short Node.js script. It inflates the compressed streams and looks for the same markers the checker uses:

const fs = require("fs");
const zlib = require("zlib");
const buf = fs.readFileSync(process.argv[2]);
const text = buf.toString("latin1");
let inflated = "";
const re = /stream\r?\n/g;
let m;
while ((m = re.exec(text))) {
  const start = m.index + m[0].length;
  const end = text.indexOf("endstream", start);
  if (end < 0) break;
  try { inflated += zlib.inflateSync(buf.subarray(start, end)).toString("latin1"); } catch (e) {}
  re.lastIndex = end + 9;
}
const all = text + inflated;
const count = (r) => (all.match(r) || []).length;
console.log({
  tagged: /\/Marked\s+true/.test(all),
  language: (all.match(/\/Lang\s*\(([^)]*)\)/) || [])[1],
  displayDocTitle: /\/DisplayDocTitle\s+true/.test(all),
  formFields: count(/\/Subtype\s*\/Widget/g),
  fieldTooltips: count(/\/TU\s*[(<]/g),
  xfaForm: /\/XFA/.test(all),
});

The full run, which also counted pages, the stored title, the structure tree, and figure tags, reported:

{
  "pages": 6,
  "tagged": true,
  "structTree": true,
  "language": "en-US",
  "title": "Form W-9 (Rev. March 2024)",
  "displayDocTitle": false,
  "formFields": 23,
  "fieldTooltips": 0,
  "xfaForm": true,
  "taggedFigures": 0,
  "altTexts": 0
}

• Passes the basics - the file is tagged, has a structure tree, and declares en-US as its language.
• Title not shown - the title is stored, but DisplayDocTitle is not set, so viewers show the file name. That is the second half of Acrobat's Title fix: Initial View > Show: Document Title.
• Field descriptions live elsewhere - the 23 form fields carry no Tooltip in the standard form layer. Their descriptions sit in the file's XFA layer instead, which not every PDF viewer reads, so test the fields with a screen reader in the viewer your users actually have.

A script like this is useful for triaging many PDFs at once, but it only reads markers. Reading order and the quality of alternate text still need a person, as covered in the guide to PDF testing.

Which Laws Cover PDF Accessibility?

• Section 508 - the Revised 508 Standards apply WCAG 2.0 Level A and AA to non-web documents, which are exempt from four success criteria (E205.4). See the Section 508 compliance guide.
• ADA Title II - the Department of Justice web rule fact sheet says PDFs posted before the compliance date usually do not need to meet WCAG 2.1 AA, unless people still use them to apply for or access services. Documents posted or updated after that date must conform.

Start With the PDFs People Use to Apply for Things

Fix application forms, statements, and policies first, because those are the documents both laws keep in scope. Then test the web pages that link to them as well: TestMu AI Accessibility Testing runs WCAG scans on those pages and screen reader sessions with NVDA, JAWS, and VoiceOver, and the accessibility testing documentation covers setup.