PDF (via Print), a warning. Browser printing produces an untagged PDF: no heading structure, no table semantics, no reading order. A screen reader sees a flat text stream at best. Fine for a visual preview or an archive, not for a document that has to be accessible itself.
Acrobat Pro can auto-tag (Accessibility › Autotag Document), but the result is approximate: reading order often wrong, tables badly reconstructed, headings not hierarchical. It always needs a full manual pass, so avoid it as a default.
Word (.docx), the accessible option. The export generates a genuinely structured document: native heading styles (Heading 1, Heading 2), a table with a marked, repeating header row, a declared document language, live links, alt text on images. To keep it accessible:
- Don't replace structure with formatting: never swap a heading style for enlarged bold text
- If you add rows, stay inside the existing table rather than starting a new one without a header
- Run the built-in Accessibility Checker (Review › Check Accessibility) before you share the file
- For an accessible PDF: export from Word via File › Save As › PDF with “Document structure tags for accessibility” checked, never through browser printing
Excel (.xlsx), for tracking and sorting. The export produces a clean data range: one row per issue, no merged cells, a frozen and filterable header row, an explicit sheet name. To keep it accessible:
- Don't add merged cells: they break screen reader navigation
- Don't rely on severity colour alone: the symbol (◆ ▲ ● ▪ ○) is there for that, keep it
- If you add a tab, give it an explicit name rather than “Sheet2”
