Most inaccessible PDFs are not born in a PDF editor. They start as a Word document where headings were faked with bold text, images had no alt text, and tables had no header row. Export that file and you get a PDF that looks fine but is invisible to a screen reader. The good news: if you build the Word file correctly, creating an accessible PDF from Word is mostly automatic.
This guide walks document authors through the five things that matter most: using real heading styles, writing alt text, marking table headers, fixing reading order, and exporting a tagged PDF the right way. Get these right in Word and the resulting PDF carries the structure that assistive technology depends on.
Use real heading styles, not bold text
A screen reader user navigates a long document the way a sighted reader skims it: by jumping between headings. That only works if your headings are tagged as headings. Visually enlarging a line and making it bold does nothing for structure. You have to apply Word's built-in styles.
Select your document title and apply Heading 1 from the Styles gallery (or press Ctrl+Alt+1 on Windows). Use Heading 2 for major sections, Heading 3 for subsections, and so on. The rule is the same as on the web: do not skip levels. An H2 should never be followed directly by an H4. If you dislike how a built-in style looks, right-click it and choose Modify to change the font, size, and color, rather than abandoning the style and hand-formatting.
- Heading 1: the document title, used once.
- Heading 2: top-level sections.
- Heading 3 and beyond: nested subsections, in order.
- Normal: body text. Do not use heading styles just to make a line stand out.
When you export, each Word heading becomes a tagged <H1>, <H2>, or <H3> in the PDF, giving the reader a navigable outline. This is the single highest-impact habit for accessible documents, and it maps directly to WCAG 1.3.1 Info and Relationships.
Write alt text for every meaningful image
Every image, chart, logo, and SmartArt object needs a text alternative unless it is purely decorative. Right-click the image, choose View Alt Text (or Edit Alt Text), and type a concise description in the box. Word's auto-generated suggestions are unreliable, so write your own and untick any "generated" label. This satisfies WCAG 1.1.1 Non-text Content.
Good alt text conveys purpose, not just appearance. For a sales chart, "Bar chart showing Q3 revenue up 18 percent over Q2" is far more useful than "chart." Do not start with "image of" since the screen reader already announces it as a graphic. Keep it to roughly a sentence; if an image needs a paragraph to explain, put that explanation in the body text instead.
For images that carry no information, such as a decorative divider or a background flourish, open the Alt Text pane and tick "Mark as decorative." That tags the image as an artifact in the PDF so screen readers skip it entirely. The mistake to avoid is leaving the box empty on a meaningful image, which produces an untagged figure a reader cannot interpret.
Mark table headers and keep tables simple
Tables are where most Word documents quietly break. A data table needs a designated header row so that when a reader moves cell by cell, the screen reader can announce "Region: North, Sales: 4,200" instead of just "North, 4,200." Without header markup, the data is a meaningless grid of numbers. This is part of WCAG 1.3.1 Info and Relationships.
- Click inside the table, open the Table Design tab, and tick "Header Row." This is what associates the first row as column headers.
- Open Table Layout (or Table Properties > Row) and check "Repeat as header row at the top of each page" so the header repeats if the table spans pages.
- Avoid merged and split cells, nested tables, and blank cells used only for spacing. They confuse the reading order in the exported PDF.
Never use a table purely for visual layout, for example to place two blocks of text side by side. Layout tables get tagged as data tables and force screen reader users through phantom rows and columns. Use Word columns or text boxes positioned in line instead.
Check reading order and the document title
Reading order is the sequence in which a screen reader speaks the content, and it maps to WCAG 1.3.2 Meaningful Sequence. In a single-column document built top to bottom with styles, the order is usually correct automatically. It breaks when you use text boxes, floating images with text wrapping, or content placed in the margins, because those can be read out of sequence or skipped.
Two practical safeguards in Word: anchor images In Line with Text rather than letting them float, so they sit in the natural flow, and run the built-in checker under Review > Check Accessibility before you export. It flags missing alt text, missing table headers, and low-contrast text in one pass. Fix every error and review the warnings.
Also set the document title, which becomes the PDF's title shown in the title bar and announced first by a screen reader (WCAG 2.4.2 Page Titled). Go to File > Info, and fill in the Title field in Properties. A real title like "2026 Benefits Enrollment Guide" is far better than a filename like "final_v3_DRAFT.docx."
Export a tagged PDF the right way
This is the step where good documents get ruined. Do not use Print > Microsoft Print to PDF, and do not use a third-party "print to PDF" driver. Printing flattens your file and strips every tag, producing an untagged PDF regardless of how carefully you styled the Word document.
Instead, use File > Save As (or Export > Create PDF/XPS), choose PDF as the file type, then click the Options button. In that dialog, make sure these are ticked: "Document structure tags for accessibility" and "Document properties." On macOS, use File > Save As, choose PDF, and select "Best for electronic distribution and accessibility," not "Best for printing." These options are what carry your headings, alt text, table headers, and reading order into the PDF as real tags.
Open the result and confirm it is genuinely accessible. In Adobe Acrobat Pro, run the Accessibility checker (the Prepare for Accessibility / Check Accessibility tool). For a free, strict validation against the PDF/UA standard, use PAC (PDF Accessibility Checker). Tagged PDFs that pass these checks satisfy the core WCAG 2.2 Level A and AA requirements that the European Accessibility Act makes applicable from 28 June 2025 for in-scope products and services, via the EN 301 549 standard.
If you produce documents at scale, fix them at the source: a clean Word template with proper styles, alt text discipline, and the tagged-export setting saved as default will make accessibility the path of least resistance for everyone on your team. For a broader view of document requirements, see the PDF accessibility guide, and run a quick automated scan of your site to catch related issues on the pages that link to these files.