PDF Accessibility: A Practical Guide for Organisations Publishing Documents

Under the hood, an accessible PDF carries a tag tree — a hidden, hierarchical structure that maps every visible element to a semantic role, much like HTML. A heading becomes an <H1> tag, a paragraph a <P>, a list an <L> with <LI> children, and a data table a <Table> with <TR>, <TH> and <TD>. Screen readers ignore the visual layout entirely and read this tree instead.

A PDF exported with no tagging is called an *untagged* PDF. To a screen reader it is often just a single run of text with no structure, or — worse — a scanned image with no real text at all. The fastest test: open the file, press Ctrl/Cmd+A to select all, and try to copy the text into a plain document. If nothing comes across, or it arrives scrambled, the document needs OCR and re-tagging before anything else.

The formal target here is PDF/UA (ISO 14289), the standard for universal accessibility in PDF. It is the document-world equivalent of meeting WCAG success criteria, and it is what auditors and procurement teams increasingly ask for by name.

Tags give elements meaning; reading order decides the sequence in which they are announced. These are two separate things, and they disagree more often than people expect. A two-column newsletter can look right but read as the full left column, then the full right column, jumping mid-sentence across the page. Pull quotes, sidebars, headers and footers frequently land in the wrong place or get read twice.

Reading order is defined by the order of elements in the tag tree, not by their position on the page. In Adobe Acrobat Pro you inspect and fix it through the Tags panel and the Reading Order tool; in other editors it is the "content order" or "structure" view. The rule of thumb: read the document as a person would naturally read it aloud, and make the tag sequence match that.

• Move decorative page furniture (running headers, footers, page numbers) out of the reading flow by marking it as an artifact.
• Check that captions read immediately after the figure they describe, not three paragraphs later.
• Verify multi-column and table-heavy pages explicitly — these are where reading order breaks most often.

Alt text for images

Every image that conveys information needs a text alternative on its <Figure> tag. Describe the *meaning*, not the appearance: "Bar chart showing 2024 revenue up 18% on 2023" beats "chart." Purely decorative images — dividers, background flourishes, a logo already named in adjacent text — should be marked as artifacts so screen readers skip them entirely.

Headings that nest

Visual styling is not structure. Text that merely looks big and bold is invisible to assistive technology unless it carries an <H1>–<H6> tag. Use one <H1> for the document title, then nest logically — don't skip from <H1> to <H3>. Screen reader users navigate long PDFs by jumping between headings, exactly as a sighted reader skims, so a correct heading outline is often the single biggest usability win in a long report.

Tables with real header cells

A data table is only accessible if its header cells are tagged as <TH> (not <TD>) and given a scope of Row or Column. Scope tells the screen reader that "€4,200" belongs to the "Q3" row and the "Net revenue" column, so the value is announced with its context instead of as a bare number. Never use tables purely for visual layout — and never fake a table with tab stops or spaces, which produces meaningless output.

A frequent and costly misconception is that accessibility law stops at the web page. It does not. The European Accessibility Act (Directive (EU) 2019/882), with requirements applying from 28 June 2025, covers a range of products and services, and those requirements reach the documents those services rely on — think bank statements, e-book files, ticket confirmations, contracts and product manuals delivered as PDFs.

The technical baseline is set by the European standard EN 301 549, which references WCAG 2.2 Level A and AA. WCAG's four principles — Perceivable, Operable, Understandable and Robust — apply to non-web documents as well as web pages, which is precisely what a PDF is. Colour contrast rules carry over too: body text needs a contrast ratio of at least 4.5:1, and large text (18pt, or 14pt bold) at least 3:1 — the same thresholds as on the web (WCAG 1.4.3).

Enforcement is handled by national authorities, so fines vary by member state and can reach tens of thousands of euros, but the practical risk is simpler: a single inaccessible PDF buried in an otherwise-compliant checkout or onboarding flow can break conformance for the whole service. Microenterprises providing services (fewer than 10 staff and under €2,000,000 annual turnover) are largely exempt for those services, but most organisations publishing customer-facing documents are not.

Accessibility is far cheaper to build in at the source than to retrofit. Most remediation pain comes from fixing exported files one by one when the source document was never structured properly.

• Start in the source. Use real heading styles, list styles and table tools in Word, InDesign or Google Docs — structure exports into tags automatically when you do.
• Set the document language and title in the file properties so screen readers announce the right pronunciation and show a meaningful title in the tab.
• Tag a logical reading order and confirm it with the structure view, not just the visual preview.
• Add alt text and mark artifacts before export, not after.
• Run a checker. Acrobat's built-in Accessibility Check (and the free PAC checker for PDF/UA) catches missing tags, language and alt text. Automated tools find only a portion of issues — always finish with a manual screen-reader pass.
• Prefer HTML where you can. If a document is really just web content in disguise, publishing it as an accessible web page is almost always easier to maintain than a perfectly tagged PDF.

If you are auditing a whole site and unsure where documents sit on your priority list, our accessibility checklist puts PDFs in the context of the wider WCAG and EAA picture, and you can run a free accessibility scan of your site's pages to see where the gaps are before you commit budget.