Before You Share a Public PDF: A Practical Accessibility Review

By Pulsar Campaigns Team. Published October 28, 2026.

Consider a fictional community-meeting information sheet. It looks tidy, but its headings are ordinary bold paragraphs, its arrival directions exist only inside an image, and the website still offers an older export. A useful review follows the information through the whole publishing process.

This guide is for campaign, nonprofit and civic operations teams sharing routine public information. The examples are synthetic. Complex forms, detailed diagrams and difficult scans may need a reviewer with specific PDF accessibility experience. This workflow helps find barriers; it does not establish that a document meets every accessibility requirement.

1. Decide what people need to use

Start with the reader's task. For our fictional information sheet, a person needs to find the meeting date, understand the arrival arrangements and locate a help contact. Keep those facts in ordinary text rather than requiring someone to interpret a poster image.

Decide whether a downloadable PDF is needed and where the same essential information should appear on the public page. An HTML page or text alternative also needs review; changing the format does not automatically make information accessible.

Name the source owner, reviewer and publisher. A small team may combine these roles, but the record should identify who can fix the source and who can replace the public file. Define the approved public version before exporting it. Keep internal notes and participant details out of that version.

2. Give the editable source a usable structure

Use the authoring application's heading and list features. Making a line larger or bold changes its appearance, but does not by itself identify it as a heading in the PDF's structure. W3C's PDF heading technique describes heading tags that assistive technologies can recognize and use for navigation.

For the fictional sheet, use a document title followed by descriptive sections such as Getting there, What to bring and Getting help. Make the outline reflect the actual information hierarchy. Do not select heading levels merely to obtain a preferred font size.

Keep the reading sequence straightforward. A decorative sidebar placed beside a paragraph can make an otherwise short document harder to review. If the layout adds no useful information, consider removing that complexity in the source before trying to repair the exported PDF.

Sources: W3C PDF9: Heading tags in PDF documents

3. Check what images and links communicate

For each meaningful image, ask what a reader needs to learn from it. W3C's PDF image technique describes providing a text alternative through the image's tag. Decorative images have a separate treatment; describing every decorative element is not the goal.

If an illustration shows the route to a room, put the essential directions in the document's ordinary text as well. Write the image alternative for its purpose in that context, rather than copying a filename or trying to squeeze an entire information sheet into one image description. Confirm real arrival arrangements with the responsible venue contact before using them.

Give links a clear purpose in their surrounding text. A label such as Read the arrival information is more useful than a row of identical More links. Identify a PDF download where that helps readers understand what will open. Check that the destination actually contains the promised information; changing the label alone does not fix a broken destination.

Sources: W3C PDF1: Text alternatives for images; W3C PDF4: Decorative images and artifacts; W3C PDF11: Link annotations and structure

4. Use tables for related data

Use a table when the relationship between rows and columns helps explain the information. Do not build a page layout from a grid of blank cells. For a short list of arrival instructions, headings and paragraphs may be easier to maintain.

W3C's PDF table technique describes the table, row, header and data-cell structure needed to expose those relationships. Check the exported structure rather than assuming that a visible header row was preserved. Merged cells and complicated header arrangements require particular care.

The following examples are editorial suggestions for the fictional information sheet. They are not a report of an audit or a promise that a particular software setting will produce the right result.

Source-file changes to consider for a fictional public information sheet.
What the author notices	Source change to try	What to verify after export
Getting there is a bold paragraph	Apply the appropriate heading style	The heading is identified as a heading and available in heading navigation
Room details are aligned with spaces	Use a simple data table if rows and columns are needed	Headers and data cells have the intended relationships
Several links are called More	Write labels that distinguish their destinations	The labels and destinations remain correct in the PDF
Directions appear only in an illustration	Add the essential directions as ordinary text	Readers can find those directions without relying on the illustration

Sources: W3C PDF6: Table markup in PDF documents

5. Export using the instructions for your application

Run the source application's accessibility checker and address its findings before export. Microsoft's current guidance describes adding accessibility tags when saving Microsoft 365 files as PDFs, with different instructions for Windows, macOS and the web. Use the instructions for the application and version you actually have.

For example, the Windows instructions include a document-structure-tags option. The macOS instructions name an accessibility export option that uses Microsoft's online service. Review that data-handling path and the documented protection behavior before choosing it; do not assume every export remains local or preserves every protection setting.

Save the editable source and exported PDF as distinct files, with a clear version relationship. Open the exported file itself for review. A successful export, selectable text or a tidy screenshot is not sufficient evidence that headings, reading order and other structure work. For a scanned document, adding recognized text is a separate task from checking its structure and accuracy.

Sources: Microsoft: Create accessible PDFs; W3C PDF7: Recognized text for scanned PDFs

6. Review the exported PDF in the order a reader uses it

Begin at the title and follow the document through to the help information. W3C's reading-order technique explains that tag order and the content within tags affect the reading sequence. A multicolumn page can appear correct while its content is read across the columns in the wrong order.

Use a suitable reader and the relevant assistive technology where available. Record what you actually tested. Looking at page thumbnails does not establish heading navigation, and listening to a quick read-aloud preview does not cover every assistive-technology interaction.

For links, move through the document with the keyboard and check that the sequence makes sense. Inspect table relationships, image alternatives, title and document language with appropriate tools. If a necessary check is outside the reviewer's tools or experience, leave it open and assign it rather than marking it complete.

A small review record for the fictional information sheet; these are tasks, not claimed results.
Review task	Evidence to record	If it remains open
Navigate the document's headings	Reader or assistive technology used; headings found and their order	Assign a structure review
Follow content through the page	Whether paragraphs, side content and tables are encountered in the intended sequence	Identify the first point where the sequence breaks
Use each meaningful link	Visible label, keyboard behavior and destination checked	Record the specific link and needed correction
Inspect images and tables	Alternatives and header relationships reviewed with the chosen tool	Name the element and the check still needed
Check title and language	Document properties inspected; mismatches recorded	Correct the source or export settings and review the next file

Sources: W3C PDF3: Tab and reading order; Adobe: Create and verify PDF accessibility (Acrobat Pro)

7. Treat checker results as review evidence

Adobe's Acrobat Pro guidance distinguishes results that pass, fail, need manual checking or were skipped. In particular, logical reading order needs manual verification. A report with no automatically detected failures is useful evidence, but it is not a completed review of every possible barrier.

Separate the next actions: fix a confirmed problem, carry out a named manual check, or arrange help for a check the current tool cannot perform. Record the file version, tool used, issue, owner and evidence of the correction. Keep an untested item visibly untested.

Fix repeatable problems in the editable source where practical, then export and inspect the new PDF. If a specialist must repair the PDF directly, preserve that repaired file and record the exception so a later export does not silently replace it with the earlier problem. Adobe's cited checking and repair workflow is documented for Acrobat Pro; do not assume every PDF viewer provides those features.

Sources: Adobe: Create and verify PDF accessibility (Acrobat Pro)

8. Verify the actual download and keep it current

After publication, follow the public page's link and download the file a reader will receive. Compare its version and contents with the reviewed export. Confirm that a public reader is not being sent to an editor's workspace, an old attachment or a private folder that requires an access request.

Check the accompanying page text, download label and any alternative format as well. The correct PDF is not useful if its link is misleading or the essential update appears only in a different version. Publish only the information approved for public distribution.

Keep one owner for corrections and a short release record: source version, exported filename, public URL, review date, checks completed and open issues. When the content changes, update the source, review the new export and replace the intended public copy through the organization's normal process. Do not carry an earlier review date forward as evidence for a file that has changed.

Make the review describe what happened

A useful sign-off identifies the exact file, the checks performed and any remaining limitations. It does not simply say that the page looked fine. Keep that record with the editable source so the next person can maintain the document without starting from an unexplained export.

Sources and review

Primary guidance checked for document structure, export behavior and PDF review. W3C techniques illustrate ways to address particular accessibility needs; they are not an exhaustive checklist. Follow the current instructions for your application and the requirements relevant to your organization.

Sources checked October 28, 2026.