EZ508 Section 508 document remediation

How to make a PDF accessible: a practical checklist

An accessible PDF is one a screen reader can navigate, a magnifier can reflow and a keyboard user can operate. Getting there is mostly about the structure hidden inside the file. This is the full checklist, in the order it is easiest to work through.

Updated

1. Start from the source file if you can

Most accessibility problems in a PDF were created upstream, in Word, InDesign or PowerPoint, and are far cheaper to fix there. Real heading styles, alt text and table header rows set in the source carry through to the PDF when it is exported properly. If you have the .docx, fix that and re-export. The Word guide covers how.

Never "print to PDF". Printing throws the structure away. Use Save As or Export with the accessibility (tagging) option turned on.

2. Scanned pages need OCR first

A scanned page is a photograph of text. There are no characters in it to read, select, search or tag. To check, try to select a sentence: if you get a box around the whole page instead, it is an image. Run optical character recognition (Acrobat's "Scan & OCR", or a dedicated OCR tool) before anything else on this list, then proofread the recognised text, because OCR mistakes become the words a screen reader speaks.

3. Tag the document

Tags are the PDF's hidden structure tree, the equivalent of HTML markup. They say "this is a level-2 heading", "this is a list of four items", "this is a table with these header cells". Assistive technology reads the tags, not the visual page. An untagged PDF is, to a screen reader, an undifferentiated stream of text, sometimes in the wrong order.

Every piece of real content must sit inside a tag, and every tag must be the right kind. A heading tagged as a plain paragraph (P) passes an "is it tagged?" check but still fails the user.

4. Title and language

  • Document title. Set a descriptive title in the document properties, and set the PDF to display that title, not the file name, in the window's title bar. "FY26 Budget Justification" is what a screen reader should announce, not "final_v3_REVISED.pdf".
  • Language. Set the document's primary language (for example, English) so screen readers choose the right pronunciation rules. Passages in another language should carry their own language setting.

5. Headings

Headings are how screen-reader users skim. Most jump from heading to heading to find the section they want. Tag every visual heading as H1–H6 to match the document's real outline, and don't skip levels: an H2 section shouldn't contain an H4 with no H3 between. Don't use heading tags just to make text look big.

6. Reading order

The order of the tags is the order a screen reader reads. Multi-column layouts, sidebars, pull quotes, text boxes and footnotes are the usual problems: the visual layout makes sense, but the tag order jumps between columns or drops a sidebar into the middle of a sentence. Check the tag tree from top to bottom against how a sighted reader would read the page.

Acrobat also keeps a separate "content order", used when a page is reflowed. It should agree with the tag order.

7. Images and alt text

Every image that carries meaning needs a Figure tag with alternative text that conveys what the image is there to communicate. A chart needs its takeaway and, if the data matters, the data in a table or the surrounding text. The alt text guide covers how to write good descriptions.

Images of text, such as a scanned signature block or a screenshot of a table, should either be replaced with real text or have that text in their alt text.

8. Decorative content and page furniture

Some things on a page shouldn't be read at all: decorative lines and backgrounds, ornamental images, and the running headers, footers and page numbers repeated on every page. Mark them as artifacts so they are skipped. Otherwise a reader hears "Department of Example, page 14 of 60" in the middle of every paragraph that crosses a page break.

9. Tables

  • Use table tags (Table, TR, TH, TD) for data tables only, never for laying out a page.
  • Mark header cells as TH and give them a scope (column or row) so each data cell can be announced with its headers.
  • Keep the structure regular: every row should have the same number of cells once spans are counted. Avoid merged cells where you can; complex tables may need explicit header-to-cell associations (IDs and Headers).
  • A table that continues onto a second page should still be one table in the tags, not two.
  • Add a caption or a preceding heading that says what the table shows.

10. Lists

Bulleted and numbered lists should be tagged as lists (L containing LI items, each with a Lbl for the bullet or number and an LBody for the text). A screen reader then says "list, five items", which tells the listener how much is coming.

Each link needs a Link tag tied to its link annotation, and link text that makes sense out of context. "Read the full 2026 audit report" works when a screen-reader user pulls up a list of links; "click here" and a bare URL don't.

12. Colour and contrast

  • Body text needs a contrast ratio of at least 4.5:1 against its background; large text (18 pt, or 14 pt bold) at least 3:1. Light grey text and text over photos are the usual failures.
  • Don't rely on colour alone. Charts that distinguish series only by colour, or forms that mark required fields only in red, need a second cue, such as labels, patterns or a symbol.

13. Fonts and text

Fonts should be embedded, and every character should map to a real Unicode value. When a font's mapping is missing, a PDF can look perfect yet read aloud as gibberish, or copy and paste as random symbols. This usually comes from unusual fonts or old conversion tools and has to be fixed in the source or by re-exporting.

14. Bookmarks

For anything longer than a few pages, add bookmarks that mirror the headings. They give every reader, not just screen-reader users, a clickable outline. Word can generate them from heading styles on export.

15. Forms

Fillable fields need a tooltip (the accessible name) that says what to enter, a logical tab order, and their own tags. Instructions and required-field indicators should be in text, not just colour. Form remediation is a specialist job; test any form you publish with a keyboard and a screen reader.

16. Test it

  1. Run an automated check. Acrobat Pro's accessibility checker is the familiar one. The free PAC (PDF Accessibility Checker) tests against PDF/UA and is stricter. veraPDF is an open-source PDF/UA validator.
  2. Review what software can't. Read the alt text, scan the heading outline, and walk the tag tree against the page.
  3. Listen to it. Open the file in a screen reader such as NVDA (free) and move through it by headings, then by links, then read a table. Ten minutes of listening finds problems no checker reports.

Where EZ508 fits. EZ508 automates most of steps 3 to 14 on Word and PDF files. It tags structure, sets the title and language, writes alt text for you to review, corrects reading order, marks artifacts, repairs table headers and lists, fixes low-contrast text and builds bookmarks. Then it runs two independent checks and gives you a report. It doesn't OCR scanned pages or remediate fillable forms, and you should still review the result yourself.

This guide is general information, not legal advice. Check your own agency's or organisation's accessibility requirements before publishing.