The Core Principle: Accessibility Starts in Word, Not in the PDF
A tagged PDF is not a goal in itself — it is the result of a document that has been correctly structured from the outset. Word can export structure tags to PDF, but only for the structure that actually exists in the Word file. If headings have been created by making text bold and large — rather than using Word’s built-in heading styles — they will be exported as ordinary paragraphs in the PDF, regardless of which export settings are chosen.
This means that accessibility work happens primarily within the Word document, and the export step simply preserves what is already there.
Step 1: Use Word’s Built-In Heading Styles
The single most important factor for an accessible PDF is consistent use of Word’s built-in heading styles: Heading 1, Heading 2, Heading 3, and so on. These styles map directly to PDF structure tags such as H1, H2, and H3, which screen readers and other assistive technologies use to navigate the document.
Custom styles — for example, a style you have named “MyHeading” — will by default map to a <P> tag in the exported PDF, regardless of how they appear visually. Always use the built-in styles, and adjust their appearance afterwards via “Modify Style” if needed.
A logically hierarchical structure is essential: use Heading 1 for the document’s title or primary sections, Heading 2 for subsections, and Heading 3 for further nesting. Do not skip levels — do not jump from Heading 1 directly to Heading 3. This creates a confusing navigation structure for screen reader users and constitutes a failure of WCAG 2.1 Success Criterion 1.3.1 (Info and Relationships).
Step 2: Add Alt Text to Images
All images that convey information must have descriptive alternative text — alt text — that explains the image’s content or function. Purely decorative elements should instead be marked as decorative, so that screen readers can skip them.
In Word, you add alt text by right-clicking on an image and selecting Edit Alt Text. Here you can either write a description or check the “Mark as decorative” box. The alt text is transferred automatically to the PDF on export, provided you use Word’s built-in export function.
Good alt text describes what the image shows and — where relevant — what it is used for. “Chart” is insufficient. “Bar chart showing that 73% of municipal websites comply with WCAG 2.1 AA in 2025” gives the user the relevant information.
Step 3: Structure Tables Correctly
Tables are a frequent source of accessibility errors in PDF documents. A table must have a clear header row that describes the content of each column — and ideally a caption or title explaining what the table shows.
In Word, you specify that the top row is a header row by clicking within the table and enabling Table Layout → Repeat Header Rows. This is also the setting that ensures the screen reader announces the column name when the user navigates cells in subsequent rows. Without a header row, table data is presented as a stream of numbers and text with no context.
Avoid using tables for layout purposes — for example, to place text in columns. Such tables create a confusing reading order for assistive technologies. Use Word’s column formatting or text boxes instead.
Step 4: Set the Document Title in Metadata
An accessible PDF document must have a descriptive title in the document’s metadata — not merely a filename. This is a requirement of the PDF/UA standard and ensures that screen readers can announce the document’s name correctly, and that the document is searchable and identifiable in archives.
In Word, you set the title under File → Info → Properties (Windows) or File → Properties (Mac). Fill in the Title field with a precise and descriptive name — for example, “Guidance on Disproportionate Burden — Accessibility Exemptions for Public Authorities 2025”. The title is transferred to the PDF’s metadata on export.
Step 5: Run Word’s Accessibility Checker
Before exporting, run Word’s built-in Accessibility Checker. You will find it under Review → Check Accessibility (Windows and Mac). The checker analyses the document and highlights issues including missing alt text, incorrect table structure, missing heading structure, and other factors that affect accessibility.
The Accessibility Checker does not catch all issues — it does not cover colour contrast or links with unclear link text, for example — but it is a useful first filter that identifies the most obvious structural errors. Correct all errors and warnings before exporting.
Step 6: Export Correctly to PDF
The export step is critical, and this is where many make the mistake of using the wrong method. Two rules apply to all versions of Word:
Never use “Print to PDF”. Printing to PDF bypasses Word’s export engine and produces an image-based, untagged PDF document. It is effectively a scanned version of the document and is inaccessible to screen readers in the same way as a scanned PDF.
Always use “Save As” → PDF. Go to File → Save As (or “Save a Copy”), select PDF as the file format, and save.
On Windows, an export dialog appears. Click Options and check that the following are selected under “Include non-printing information”:
- Document structure tags for accessibility — this is the critical checkbox
- Create bookmarks using: Headings — gives screen reader users direct navigation within the document
- Document properties — transfers the title you set in step 4
Note: If you select “Minimum size” to reduce the file size, this can automatically uncheck the document structure tags option. Always verify the settings again if you have used this option.
On Mac, select PDF as the file format and ensure that “Best for electronic distribution and accessibility” is checked. In recent versions of Word for Microsoft 365, tags are exported automatically via Save As → PDF, and there is no separate Options dialog.
What Word’s Export Does Not Guarantee
Word’s PDF export is not a guarantee of full PDF/UA compliance. It is important to understand the limitations.
Documents with complex layouts — multiple columns, floating text boxes, complex tables — may produce errors in the tagging structure that require manual correction in Adobe Acrobat Pro. Empty paragraphs used for vertical spacing are exported as empty <P> tags, which create noise for screen readers — use Paragraph spacing (space before/space after) in the paragraph style settings instead. Complex tables with merged cells and multiple header levels are not fully supported by Word’s export engine.
For documents with simple to moderate layouts, Word’s own export function in Microsoft 365 generally produces better results than third-party plugins such as Adobe Acrobat PDFMaker, according to accessibility specialists working with PDF verification.
From Tagged PDF to HTML
A tagged PDF is a far better starting point than an untagged one — but even well-prepared PDF/UA documents provide a poorer user experience for screen reader users than well-structured HTML. Navigation in PDFs is generally more complex and less predictable than in HTML pages, and PDFs do not support the same degree of user-controlled adjustment of font size and contrast.
For public authorities wishing to make existing PDF documents accessible on the web, converting to HTML is in many cases a more effective alternative than manually correcting PDF/UA issues. PDFAccess converts PDF documents to WCAG 2.1 AA-compatible HTML directly in the browser — without data leaving the device.
Checklist: Word to Accessible PDF
Use this checklist before exporting:
- All headings are formatted using Word’s built-in heading styles (Heading 1, 2, 3)
- The heading hierarchy is logical — levels are not skipped
- All informative images have descriptive alt text
- Decorative images are marked as decorative
- Tables have a header row marked via “Repeat Header Rows”
- Tables are not used for layout purposes
- Document title is set under File → Info → Properties
- The Accessibility Checker has been run and all errors corrected
- Export is done via Save As → PDF — not via Print to PDF
- The “Document structure tags for accessibility” checkbox is selected (Windows)
- File size optimisation has not removed the accessibility checkbox