PDF

How to make a PDF accessible

The cleanest repair usually begins in the source document. Build headings, lists, tables, alternatives, and reading order there, then verify what survived the PDF export.

Find the best source before touching the PDF

If the PDF came from Word, InDesign, a publishing system, or generated HTML, inspect that source first. Repairs made there can survive the next export and benefit every future version. A PDF-only repair may be necessary for an old file with no usable source, but it is easy to lose when someone republishes the document from the original template.

Use authoring features that carry meaning

Apply built-in heading styles instead of changing font size and weight by hand. Create real lists. Use simple data tables with a designated header row. Add link text that makes sense outside the surrounding sentence. Give images alternatives based on their purpose, and mark decorative images as decorative where the authoring tool supports it.

Set the document language and a useful title. Check color contrast and do not use color as the only cue. These choices are easier to manage in the authoring tool than in a finished PDF.

Accessible PDF work begins before export
Accessible PDF work begins before exportAuthoring structure enters the export. The finished PDF then needs a separate preflight because conversion can change tags, order, and metadata.

Export with accessibility information enabled

Use the application's PDF export rather than printing to a PDF driver when the export can retain tags, bookmarks, links, language, and document metadata. Settings vary by product and version, so save the approved export settings with the publishing workflow instead of relying on memory.

An export can report success while producing a weak tag tree. The source may contain a complicated table, grouped objects, floating text boxes, or custom styles that map poorly. Open and inspect the PDF that people will receive.

Run technical checks on the PDF

Check for machine-readable text, a tagged structure, language and title metadata, heading hierarchy, list and table semantics, image alternatives, link annotations, form field properties, and suspicious reading order. A validator can find structural failures consistently and record the affected object.

Technical results need coverage. Some checks are deterministic. Others can only flag a condition for review. For example, software can detect missing alternative text but cannot reliably decide whether supplied text communicates the image's purpose.

Read the document in its intended order

Move through headings, links, form controls, and table cells with keyboard and assistive technology. Check that columns, notes, and captions appear in a sensible sequence. Zoom and reflow where supported. Make sure instructions and errors do not depend on visual position alone.

Repair, then retest the delivered file

Fix source-level issues in the source. Use a PDF remediation tool for problems that only exist in the output or when no source is available. Keep a note of each decision, especially for reading order, table structure, and alternative text. Retest the exact file that will be published and keep that result with the release.

Sources