Image description: Hands tagging a PDF document on a laptop with the Acrobat tags panel visible — close-up of the accessibility-remediation workflow at the document layer.

Reading Time: 10 minutes

To make a PDF accessible, you need a logical tag tree, meaningful alt text on every informative image, a defined reading order that matches the visual layout, accurately marked-up forms and tables, and a declared document language. None of that is automatic. Every step below is a step a human has to perform — usually in the authoring tool (Word, InDesign) before export, sometimes in Acrobat Pro after. This is the step-by-step playbook.

The deeper conceptual treatment — what PDF/UA-1 actually requires, how the Matterhorn Protocol maps to the tag tree, how JAWS, NVDA and VoiceOver each interpret the same tagged file differently — lives in the end-to-end PDF accessibility explainer. This page is the hands-on companion: open it next to your authoring tool and work through each step in order.

Step 1 — Start with an accessible source document

Get it right BEFORE you export to PDF. Almost every cheap-to-fix issue in PDF accessibility traces back to a source document that was formatted by hand instead of by style.

In Microsoft Word (Microsoft 365, 2026 build)

  • Use the built-in Heading 1, Heading 2, Heading 3 styles from the Home tab. Do not fake a heading by selecting text and pressing Bold + bumping the font size. The exporter cannot guess your intent — it only reads style names.
  • Add alt text on every informative image: right-click the image, View Alt Text, type a description, and tick Mark as decorative for purely ornamental graphics.
  • For data tables, use Insert > Table, then under Table Design check Header Row, and under Layout check Repeat Header Rows. That tells the exporter which row is the header.
  • Set the document language under File > Options > Language, and set per-paragraph languages via Review > Language > Set Proofing Language for any quoted passage in another language.
  • Use the Review > Check Accessibility pane before exporting. It catches the obvious misses.

In Adobe InDesign (2026)

  • Build a Paragraph Styles sheet where each style is mapped to a PDF tag under Export Tagging in the style options. H1, H2, P, Caption — every style needs a target.
  • Set reading order via the Articles panel (Window > Articles). Drag stories and images into the order a screen reader should hear them. Without this, the exporter falls back to geometric order, which fails for multi-column layouts.
  • Add alt text on every image via Object > Object Export Options > Alt Text.
  • Set the document language under File > File Info > Basic, and confirm it in File > Export > Adobe PDF Presets.

Step 2 — Export with the accessibility flag set

How you export matters as much as how you authored.

Word: Go to File > Save As, pick PDF, then click Options. In the dialog, tick Document structure tags for accessibility and Document properties. Untick Bitmap text when fonts may not be embedded — that flag destroys the text layer. Save.

InDesign: Go to File > Export, choose Adobe PDF (Print), not Interactive. In the General tab, tick Create Tagged PDF. In the Advanced tab, confirm the document language is set. If your document has forms, choose Adobe PDF (Interactive) instead, but be aware Interactive PDFs need extra form field tagging in Acrobat afterwards.

Do not use File > Print > Save as PDF (Word) or Print > PDF > Save as PDF (macOS). That route renders the document to a flat page image with no tags, no reading order and no metadata. You will then be remediating from scratch in Acrobat — hours of work instead of the minute that proper export takes. This single mistake accounts for the majority of “untagged PDF” findings in audits.

Step 3 — Verify and fix in Acrobat Pro

Open the exported PDF in Adobe Acrobat Pro (2026). Open the Accessibility tool via View > Tools > Accessibility > Open.

Run Full Check first. Accept the defaults and let it scan. It will produce a tree of pass/fail items in the Accessibility Checker panel on the left. Click each failed item to highlight the offending location.

Then open the Tags panel (View > Show/Hide > Navigation Panes > Tags) and the Reading Order tool (in the Accessibility panel). The tag tree is the structural skeleton — every paragraph, heading, image, table cell and link should appear as a tag in the right order.

Common fixes at this step:

  • Decorative images announced as content. In the Reading Order tool, draw a box around the image and click Background/Artifact. Screen readers will now skip it.
  • Headings mis-nested under paragraphs. Drag the heading tag in the Tags panel out of the parent <P> and up to the top level.
  • Reading order doesn’t match the visual order. Use the Reading Order tool’s number overlay to see what order the screen reader will use. Re-tag elements until the numbers match the eye-path.
  • Empty tags from copy-paste artifacts. Delete them in the Tags panel — they cause screen readers to announce silent gaps.

Save the file when the Full Check shows only intentional warnings (e.g. “logical reading order” is always flagged for manual review — that’s expected).

Step 4 — Forms, tables and links

These three areas need careful attention beyond the automatic tagging.

Forms. Every form field in an accessible PDF needs a tooltip that announces the field label, and the fields need a logical tab order. In Acrobat Pro, go to Tools > Prepare Form. Acrobat auto-detects fields; review each one. Double-click a field, open the General tab, and set the Tooltip to the visible label (“First name”, “Email address”, “Date of birth”). For required fields, mark Required under the Options tab — screen readers announce that state. Then open the Fields panel on the left, right-click and choose Sort by Tab Order, then drag fields into the order a keyboard user should tab through. Test by closing Prepare Form mode and pressing Tab through the document.

Tables. A simple data table — uniform rows and columns, one header row — needs its top row marked as <TH> instead of <TD> in the tag tree. Right-click each header cell in the Tags panel, choose Properties, and change the type. A complex table with merged cells or row-and-column headers needs scope attributes (column, row, colgroup, rowgroup) added in the same Properties dialog. The model mirrors HTML tables exactly. If your tables are very complex, consider whether the table is the right format — a series of simpler tables almost always reads better.

Links. Links must have meaningful link text. “Click here” or a bare URL fails every screen reader and every audit. Use Acrobat’s Edit PDF > Link > Add/Edit Web or Document Link to wrap descriptive text in a link annotation. The link tag in the tag tree should contain the visible text plus the link annotation as a child — not just a URL pointer.

Step 5 — Test the PDF the way users will read it

Automated checkers catch the structural mistakes. They do not catch the experiential mistakes — alt text that is technically present but useless, tables that are technically tagged but read in the wrong order, forms that work but feel like a maze. Only a screen-reader pass catches those.

Windows (the canonical test): Install NVDA (free, from nvaccess.org) and Adobe Acrobat Reader (free). Open the PDF in Acrobat Reader, start NVDA, and press Down Arrow to read line by line. Press H to jump heading to heading. Press T to jump to the next table, then Ctrl+Alt+Arrow keys to navigate cells. Press F to jump to the next form field.

macOS: VoiceOver + Preview does not support PDF tags well — Preview rasterises the tag tree on open. Instead, install Adobe Acrobat Reader (free) on macOS and use VoiceOver inside Acrobat Reader. The fidelity is closer to the Windows experience.

Listen for these specific signals:

  • Reading order matches the visual order on the page.
  • Alt text reads as a useful sentence — not “image1.jpg” or “Picture inserted here”.
  • Table headers announce when you navigate to a new cell (“Column: Price; Row: Subscription”).
  • Form fields announce their label and required state (“First name, edit text, required”).
  • Decorative images stay silent.

Note any failure, fix it in Acrobat, re-export and re-test. Expect at least two passes for any document over five pages.

Step 6 — Publish a remediation log alongside the PDF

For any PDF that ships under EAA, ADA Title III or Section 508 scope, publish a brief note recording that the PDF has been remediated. Two formats work:

  1. In the document properties. File > Properties > Description in Acrobat Pro. Add a line like: “Remediated for accessibility against PDF/UA-1 and WCAG 2.2 success criteria AA on 2026-05-15. Feedback: accessibility@example.org.”
  2. Alongside the download link. A one-line note on the page that hosts the PDF: “This document has been remediated for accessibility (PDF/UA-1, May 2026). Report issues to accessibility@example.org.”

This is not legally required everywhere, but it is good practice. It signals to assistive-tech users that the document was prepared with them in mind, and it gives you a defensible artefact if the PDF is ever audited.

PDF-specific common pitfalls

  • Scanned PDFs (image-only) are never accessible. OCR extracts text, but the result still has no tag tree, no headings, no reading order. Remediating a scan is authoring from scratch.
  • Auto-generated tag trees are almost always wrong. Acrobat’s Add Tags to Document button produces a tag tree, but it guesses at heading levels, often tags decorative images as figures, and tends to fragment paragraphs. Always review manually.
  • PDF/UA-1 is not WCAG 2.2. Meeting PDF/UA-1 covers most WCAG criteria that apply to PDFs, but contrast and some link-purpose checks need a separate WCAG pass.
  • Chrome’s built-in PDF viewer is not the canonical test. Forms can work in Chrome and break in Acrobat Reader, or vice versa. Test against Acrobat Reader because that is what most assistive-tech users open PDFs with.
  • InDesign’s auto-alt-text feature pulls from the image’s XMP metadata caption. If the caption is blank, the alt is blank. Always check every image in Object > Object Export Options > Alt Text before exporting.

Frequently asked questions

Is a tagged PDF the same as an accessible PDF?

No. Tags are a prerequisite, but a tagged PDF can still have wrong reading order, missing alt text, mis-nested headings, untagged form fields or decorative images announced as content. Tagging is necessary, not sufficient.

Can I make a scanned PDF accessible?

Only by re-creating it. Run OCR to extract real text, then add a full tag tree, reading order, alt text and headings as if authoring from scratch. OCR alone produces searchable text but not an accessible document.

Do I need Acrobat Pro to make accessible PDFs?

Not to author the source, but yes to verify and fix the output. Free tools like PAC 2024 can audit a PDF, but only Acrobat Pro (or specialist tools like CommonLook or axesPDF) let you edit the tag tree, reading order and form metadata.

What is PDF/UA and how does it relate to WCAG?

PDF/UA-1 (ISO 14289-1) is the technical standard for accessible PDFs. WCAG 2.2 is the broader web standard. Meeting PDF/UA-1 covers most WCAG criteria that apply to PDFs, but a few WCAG items (contrast, link purpose in some contexts) still need a separate check.

How do I test a PDF for accessibility?

Combine three checks: Acrobat Pro’s Full Check, the free PAC 2024 PDF/UA checker, and at least one real screen-reader pass with NVDA plus Adobe Reader. Automated checks find structural issues; the screen-reader pass finds the issues users actually hit.

Are PDFs required to be accessible under the ADA or EAA?

Yes in practice. Under ADA Title III, PDFs offered through a covered website are part of the goods and services the site provides. Under the EAA (in force since 28 June 2025), PDFs distributed by in-scope businesses must meet harmonised accessibility requirements, which point to WCAG 2.2 AA and PDF/UA.

Where to go next

For the deeper conceptual treatment — PDF/UA internals, the Matterhorn Protocol failure conditions, how four screen readers each render the same tagged file differently — read the end-to-end PDF accessibility explainer. To check whether the web pages that host your PDFs meet WCAG 2.2 AA, run the free WCAG 2.2 scanner over each landing page. And if PDFs are central to your compliance posture — government forms, financial disclosures, legal contracts, healthcare information — commission a manual audit by testers with disabilities. Automated checks and screen-reader passes get you most of the way; the final 10% needs human readers.