PDF Accessibility Guide

Why this matters #

PDFs are the largest single accessibility gap on most higher-ed websites. A single untagged PDF can be completely inaccessible to screen readers, keyboard users, and refreshable braille displays — even when the visual design looks fine.

You’re required to follow WCAG 2.2 Level AA and PDF/UA-1 (ISO 14289-1), the international standard for accessible PDFs. This guide covers how to create PDFs that pass — before you upload them to gallaudet.edu, where our automated checker will flag them if they don’t.

When in doubt: don’t publish a PDF. Ask if the content should be an HTML page instead. HTML is easier to make accessible, easier to update, and easier to search. Reserve PDFs for documents where the format itself matters (forms with signatures, transcripts, official publications).

---

The five things every accessible PDF needs #

Before you export or upload, verify:

• Tagged structure — headings, lists, paragraphs, tables all marked semantically
• Alt text on every meaningful image
• Reading order matches the visual order
• Language set (English or the document’s actual language)
• Document title in the file metadata (not just the filename)

If any of these are missing, the PDF is not accessible.

---

Start with the right source document #

The single biggest factor in whether your PDF is accessible is how you built the source document. A well-structured Word doc or Google Doc becomes an accessible PDF almost automatically. A poorly-structured one is nearly impossible to fix after export.

Microsoft Word #

Do:

• Use Word’s Heading Styles (Heading 1, Heading 2, Heading 3) for section titles. Never fake a heading with bold + big font.
• Use Word’s List tool for bulleted and numbered lists. Never fake a list by typing “•” or “1.” at the start of paragraphs.
• Use Insert → Table for tabular data. Never fake a table with tabs or spaces.
• Add alt text to every image: right-click → View Alt Text.
• Set the document title in File → Info → Properties → Title.
• Set the language in Review → Language → Set Proofing Language.
• Run the Accessibility Checker before exporting: Review → Check Accessibility.

Don’t:

• Use text boxes for layout — they break reading order.
• Use color alone to convey information.
• Rely on visual formatting (indentation, spacing, font size) to imply structure. Screen readers only see the tags.

Google Docs #

Do:

• Use the built-in heading styles (Heading 1, Heading 2, etc.) from the paragraph-style dropdown.
• Use bulleted / numbered list tools.
• Add alt text: right-click image → Alt text.
• Set the document language: File → Language.
• Export via File → Download → PDF Document (.pdf). This preserves tags and structure — better than “Print → Save as PDF.”

Note: Google Docs’ accessibility support is decent but not as thorough as Word’s. For high-stakes documents (policies, procedures, handbooks), Word is a stronger source.

Adobe InDesign #

Do:

• Use paragraph styles consistently.
• Set the structure order in the Articles panel: Window → Articles.
• Export as PDF (Interactive) or PDF (Print) with these boxes checked:
  • Create Tagged PDF
  • Include Non-Printing Objects
  • Bookmarks
  • Hyperlinks
• Set the document title in File → File Info → Description.

InDesign accessibility is the hardest to get right. If you export InDesign PDFs regularly, get training from the Adobe accessibility team or use a remediation tool (see below).

Adobe Acrobat Pro DC #

Acrobat Pro is where you fix PDFs after export, not where you create them. Use it to:

• Add or fix tags: Tools → Accessibility → Autotag Document
• Run the accessibility checker: Tools → Accessibility → Accessibility Check
• Fix reading order: Tools → Accessibility → Reading Order
• Add missing alt text to images

Acrobat Pro’s built-in checker is a good starting point but misses many real issues. Always pair it with a real screen reader test.

---

Section-by-section: what to check #

Document properties #

• Title set (e.g., “Financial Aid Handbook 2026”, not “handbook_final_v3.pdf”)
• Language set to English (or your document’s actual language)
• PDF/UA identifier set to true (accessibility-conformant PDFs declare this)

Set via File → Properties → Description.

Structure #

Screen readers navigate PDFs using tags — invisible markers that identify each element (heading, paragraph, list, table, figure).

Every accessible PDF needs:

• One H1 at the top (the document title)
• H2s for major sections
• H3s for subsections
• No skipped levels (don’t jump from H2 to H4)
• Real lists wrapped in <L> (list) and <LI> (list item) tags
• Real tables with <Table>, <TR> (row), <TH> (header), <TD> (data) tags
• Paragraph tags on prose

Check the tag tree in Acrobat: View → Show/Hide → Navigation Panes → Tags.

Reading order #

The tags are read in the order they appear in the tag tree — which may or may not match the visual order.

Common reading-order problems:

• Multi-column layouts where the reader jumps between columns randomly
• Pull-quotes or sidebars that interrupt the main flow
• Text boxes and floating elements that appear in unexpected places
• Headers/footers being read at the top of every page

How to check:

• Acrobat Pro: Tools → Accessibility → Reading Order — shows the reading order visually.
• Or read the PDF aloud with VoiceOver / NVDA and note anywhere the order feels wrong.

Alt text on images #

Every meaningful image needs alt text. Same rules as everywhere else:

• Meaningful, not literal: “Bar chart showing enrollment growth from 2020–2026” — not “chart.png”
• Includes the message: If the chart shows a 40% increase, say so in the alt text
• 1–2 sentences, plain language
• Purely decorative images should be marked as artifact (background pattern, page border) so screen readers skip them

In Acrobat: Tools → Accessibility → Set Alternate Text.

Complex images (charts, diagrams, infographics) #

For charts and infographics that convey data, alt text alone is often not enough. Provide:

• A short alt text (2 sentences describing what the chart shows and the takeaway)
• The underlying data in a table in the document itself, or linked as a separate file

Example: “Bar chart showing student enrollment from 2020 (2,100) to 2026 (2,940), a 40% increase. See Appendix A for the full data table.”

Tables #

Tables must be real tables, not text laid out to look like a table.

• Header row must be tagged <TH> with scope="col"
• Header column (if there is one) must be tagged <TH> with scope="row"
• Data cells are <TD>
• Merged cells are tricky — use them sparingly, and test with a screen reader
• Table title or caption should describe what the table shows

Never use tables for layout. Layout tables confuse screen readers.

Links #

• Descriptive link text: “View the 2026 academic calendar” instead of “Click here.”
• URL text is OK if the link is short and readable (“Visit gallaudet.edu/admissions”). Long URLs get read letter by letter.
• PDFs that link to other PDFs should link to the accessible version (not “download the print version”).

Color and contrast #

Same rules as digital:

• Text contrast: 4.5:1 for body text, 3:1 for large text (18pt+ or 14pt+ bold)
• Don’t rely on color alone to convey information
• Print-color-safe: assume the PDF may be printed on a black-and-white printer

Forms (if the PDF is a fillable form) #

If your PDF has fillable fields (a scholarship application, a form-to-return):

• Every field needs a label (tooltip in Acrobat)
• Required fields should be marked as required
• Tab order should match the visual order
• Radio buttons and checkboxes need labels and group labels
• Test with a keyboard — every field must be reachable and usable without a mouse

Fillable forms are the trickiest kind of accessible PDF. If the form is complex, consider converting it to an HTML form instead — HTML forms are much easier to make accessible.

Scanned PDFs #

A scanned PDF is an image of text — screen readers see nothing.

• Run OCR (Optical Character Recognition) first: Acrobat Pro → Tools → Scan & OCR → Recognize Text
• After OCR, add tags and structure as if it were a new document
• Alt text is still needed on images embedded in the scan

A scanned PDF that hasn’t been OCR’d is unpublishable. Full stop.

---

Testing your PDF #

Automated checks #

• Adobe Acrobat Pro Accessibility Checker: Tools → Accessibility → Accessibility Check
  • Runs Adobe’s 32-item WCAG-mapped check
  • Reports pass/fail/needs-manual-check per item
  • Fixes what it can automatically
• Gallaudet’s automatic upload check (Adobe’s PDF Accessibility Checker)
  • Every PDF you upload to the Media Library is auto-checked, with the same checks as Acrobat Pro
  • Failures create a Slack alert + Asana ticket for the web team
  • You don’t need to run this yourself — but if your PDF fails, expect a follow-up
• PAC 2024 (free desktop tool for Windows)
  • Industry-standard PDF/UA checker
  • Download from pdfua.foundation
  • Best for high-stakes documents

Manual checks #

Automated checkers catch about 30% of real accessibility issues. The other 70% requires human review:

• Read the PDF with VoiceOver (Mac) or NVDA (Windows, free) for 60 seconds
• Navigate with keyboard only — Tab, arrows, Enter. Can you reach everything?
• View at 200% zoom — does anything get cut off?
• Read in “high contrast mode” — does color-only information disappear?

Confirming a PDF was reviewed #

When you link a PDF in a GUCE page, a notice suggests turning it into a Resource or Guideline page instead. If you keep the PDF, the notice lets you confirm that it was reviewed for accessibility (see When GUCE asks about a PDF you link).

Confirm only after you’ve checked the PDF against this guide:

• It has passed an automated check (Acrobat’s Accessibility Checker or PAC), and any problems Gallaudet’s checker reported are fixed
• You did the manual checks: a screen reader, keyboard only, and 200% zoom
• Its images have alt text, its tables have headers, and it reads in the right order

Your confirmation is recorded with your name, the date and the exact version of the file, and the web team can see it in the Media Library. It covers that file for everyone, so other editors who link it aren’t asked again. If the file is replaced, the next editor who links it is asked again.

---

What to do when your PDF fails Gallaudet’s check #

When you upload a PDF to gallaudet.edu, our automated checker runs within seconds. If your PDF fails, you’ll see:

• A red ⚠ N issues badge in the Media Library
• A Slack message to the web team (they’ll follow up)
• An Asana ticket for remediation

You have three paths:

Option 1: Fix the source and re-upload #

• Open the source document (Word, InDesign, etc.)
• Fix the issues flagged in the report
• Re-export and re-upload
• The check re-runs automatically; the ticket auto-closes when it passes

Option 2: Convert to an accessible HTML page #

• In GUCE, click New Page from PDF on your dashboard (see Turn PDFs into Webpages). In WordPress admin, click “Convert to accessible HTML page” on the failing PDF in the Media Library
• The converter creates a draft Resource or Guideline page from the PDF content
• Check the images it found and their alt text, replace any image placeholders that are left, review the draft, then publish
• This is often the better choice for text-heavy content

Option 3: Remediation #

For complex documents where source-fix isn’t possible:

• AbleDocs — Gallaudet has (or can procure) remediation service contracts
• CommonLook — desktop tool for hands-on remediation
• Contact the web team at gu.live/request for guidance

---

When to NOT use a PDF #

Ask yourself these questions. If the answer to any is “no,” consider an HTML page instead:

• Does the format itself matter? (Legal signatures, transcripts, official documents = yes; a policy page = no)
• Will the content stay stable for at least a year? (Weekly-updated content should never be a PDF)
• Does the audience need to print or download it?
• Is the content too long or complex for a web page?

Content types that should almost never be PDFs:

• Announcements, news, blog posts
• Event listings, schedules
• Department pages, contact info
• Policies (unless the signed original is legally required)
• Anything the user might read on a phone

Content types where PDFs make sense:

• Signed legal documents
• Official transcripts
• Print-quality collateral (brochures for mailing)
• Handbook / catalog archives (with a companion HTML version)
• Forms that require handwritten signatures

---

Quick reference: PDF/UA and WCAG rules #

For anyone who needs to cite the standards:

---

PDF accessibility tools we support #

Free:

• NVDA (Windows screen reader) — the standard for testing
• VoiceOver (Mac, built-in) — for testing
• PAC 2024 (Windows) — best free PDF/UA checker
• PDF Accessibility Checker in Adobe Reader (limited)

Paid / already licensed at Gallaudet:

• Adobe Acrobat Pro DC — for tagging, remediation, and checking
• Microsoft Word — for creating accessible source documents
• Adobe PDF Accessibility Checker — runs automatically on upload; you never touch it directly

Advanced / when you need help:

• AbleDocs remediation service — for high-volume or complex documents
• CommonLook Desktop — for hands-on remediation

---

Need help? #

Submit a ticket at gu.live/request for:

• Guidance on whether a specific document should be a PDF or an HTML page
• Help with a PDF that consistently fails the automated check
• Bulk migration help (a whole department’s back catalog)
• Access to remediation services for high-stakes documents
• Training for you or your team on PDF creation

The web team responds within 5 business days.