A PDF is accessible when it includes a logical tag structure, correct reading order, alternative text for images, labeled form fields, and WCAG 2.1 AA-compliant document semantics that allow screen readers to interpret the content correctly.
PDF accessibility is where most public agencies have their largest unmanaged compliance exposure. Not because the problem is technically complicated. Because the people creating and uploading documents have never been told what "accessible" actually means in practice, what it looks like when a document fails, and what specific steps produce a document that works for everyone.
This guide fixes that. It is written for the staff who actually create and publish documents — the communications coordinator, the department admin, the board secretary, the permit technician — not for developers or accessibility specialists. If you create documents in Microsoft Word, Google Docs, or Adobe InDesign and publish them as PDFs, this guide covers exactly what you need to do.
By the end of it you will know: what makes a PDF inaccessible, how to create an accessible PDF from the most common government document tools, how to check a PDF for accessibility before you upload it, and how to remediate a PDF that was created without accessibility in mind.
What Makes a PDF Inaccessible (And Why It Matters for ADA Compliance)
Before getting into the how-to, it helps to understand what is actually happening when someone with a disability tries to read an inaccessible PDF.
A person who is blind uses a screen reader — software that reads digital content aloud. When a screen reader encounters a PDF, it does not see the document the way a sighted person does. It reads the document's underlying structure: the tagged elements, the defined reading order, the programmatic associations between labels and content. If that structure does not exist — or is wrong — the screen reader cannot interpret the document correctly.
Here is what that actually sounds like in practice.
Example: A scanned board agenda read by a screen reader
What the document looks like visually: a clean, formatted agenda with the meeting date, call to order, approval of minutes, and agenda items listed clearly.
What the screen reader announces: "Image. Image. Image. Image."
That is it. The entire document is a flat image. There is no text layer. No structure. No information. A blind resident trying to review the agenda for a public meeting hears nothing useful.
Example: An exported PDF with wrong reading order
A two-column permit application exported from InDesign without accessibility settings reads like this to a screen reader: "Applicant Name Property Address Date of Application Business License Number Contact Phone" — reading across both columns simultaneously rather than down each column in sequence. The information is technically present but navigated in an order that produces nonsense.
Example: A form with visual labels but no programmatic associations
A form that looks correct on screen — with "First Name" printed next to a text field, "Date of Birth" next to another — announces this to a screen reader user: "Edit text. Edit text. Edit text." Every field sounds identical. The user has no idea what information each field is asking for.
These are not edge cases. They are the default state of most government PDFs that were not created with accessibility in mind.
The Three Types of Inaccessible PDFs (WCAG Accessibility Failures)
Understanding which type of inaccessible PDF you are dealing with determines the remediation approach.
Type 1: Scanned image PDFs Created by scanning a physical document or printing to PDF from a file and then scanning. The entire document is one or more flat images. There is no text layer. Screen readers see nothing. These require OCR processing plus full accessibility tagging.
Type 2: Untagged exported PDFs Created by exporting from Word, InDesign, or another application without enabling accessibility settings. The text is present and selectable, but there is no tag structure, no defined reading order, no heading hierarchy, and no alternative text for images. These require accessibility tagging, either through the source application or through Adobe Acrobat.
Type 3: Incorrectly tagged PDFs Created with accessibility settings enabled but with errors — wrong heading levels, missing alternative text on some images, tables without header associations, incorrect reading order in multi-column layouts. These require targeted remediation of the specific errors rather than a full retagging.
Most new documents you create fall into Type 2. Most historical documents in your agency's library fall into Type 1 or Type 2. Type 3 is the most common result of an initial accessibility effort that was incomplete.
Show Me, Don't Just Tell Me
Use the tabs below to see exactly what each failure looks like — and what the correct version looks like — before we walk through how to create accessible PDFs from each tool.
PDF Accessibility: Before & After
Five tabs covering the most common PDF accessibility failures in government documents — what each failure looks like, what the screen reader announces, and exactly how to fix it.
The three types of inaccessible PDFs and what each one requires
Created by scanning a physical document or printing to PDF then scanning. The entire document is a flat image — no text layer, no structure. Screen readers see nothing at all.
Requires: OCR processing to add text layer + full accessibility tagging
Created by exporting from Word or InDesign without accessibility settings. Text is present and selectable but there is no tag structure, no heading hierarchy, no reading order. The most common type for new government documents.
Requires: Return to source file and re-export with accessibility tags enabled, or tag in Acrobat
Created with accessibility settings but with errors — wrong heading levels, missing alt text on some images, tables without header associations, wrong reading order in multi-column layouts.
Requires: Targeted remediation of specific errors rather than full retagging
Most new documents you create
Are Type 2. The text is there. The structure is not. Fix it at the source — in Word before you export — and you avoid Acrobat remediation entirely.
What the PDF tag tree looks like — inaccessible vs. accessible
P: POSITION ANNOUNCEMENT
P: Job Title: Senior Permit Tech
P: Department: Community Dev
P: ESSENTIAL DUTIES
P: Reviews permit applications
P: Coordinates with inspectors
P: MINIMUM QUALIFICATIONS
P: High school diploma required
H2: Department and Location
P: Community Development H2: Essential Duties
L: LI: Reviews permit applications LI: Coordinates with inspectors H2: Minimum Qualifications
P: High school diploma required
Screen reader on untagged version:
"City of Springfield. Position Announcement. Job Title Senior Permit Tech..." [continuous paragraph, no navigation points]
Screen reader on tagged version:
"Heading level 1: Senior Permit Technician. Heading level 2: Department and Location. Heading level 2: Essential Duties. List of 2 items..." [user can jump directly to any section]
Why this matters
Screen reader users navigate PDFs by jumping between headings. Without heading tags, they must listen to the entire document from the beginning every time. A 40-page board packet without structure takes hours to navigate.
The exact Word export settings that determine whether your PDF has accessibility tags
The correct export path in Microsoft Word
Go to File > Save As or File > Export
↓
Select PDF as the file format
↓
Click More Options — not just Save
↓
In the dialog, click Options...
↓
Configure the checkboxes below, then click OK and Save
Required checkbox settings
Document structure tags for accessibility
This is the critical one. Without it, all heading structure, alt text, and list formatting is discarded on export.
Document properties
Exports the document title and language settings into PDF metadata. Required for screen readers to identify document language correctly.
Bitmap text when fonts may not be embedded
Leave unchecked. Enabling this converts text to images, removing the text layer and making the PDF inaccessible.
What NOT to use
This export method destroys all accessibility structure:
File > Print > Microsoft Print to PDF
Why Print to PDF fails
Print to PDF treats the document like a printed page — flat visual output with no structural tags. Every heading, list, and alt text you added in Word is discarded regardless of how well you built the source document.
Heading styles vs. manual bold formatting — the most common source of PDF structure failures
All applicants must submit
the following documents:
Financial Documents
- Tax returns (2 years)
- Bank statements (3 months)
Bold + larger font. Looks like a heading. Has no structural meaning.
All applicants must submit
the following documents:
Financial Documents
- Tax returns (2 years)
- Bank statements (3 months)
Heading 2 style from the Styles panel. Looks identical. Has full structural meaning.
Screen reader on manual formatting:
"Section 3 Requirements. All applicants must submit the following documents. Financial Documents..." [reads as body text, no heading navigation]
Screen reader on Heading styles:
"Heading level 2: Section 3 Requirements. Heading level 2: Financial Documents. List of 2 items..." [user can jump directly to any H2]
Where to find heading styles in Word
Home tab, Styles panel. Select text first, then click the style. Heading 1 for the title, Heading 2 for major sections, Heading 3 for sub-sections, Normal for body text. Never use bold plus font size as a substitute.
Table headers — the difference between data a screen reader can interpret and data it cannot
| Fee Type | Standard | Reduced |
| Commercial | $250 | $175 |
| Residential | $150 | $100 |
Header row looks bold visually. No TH tags. Screen reader has no column context.
| Fee Type | Standard | Reduced |
|---|---|---|
| Commercial | $250 | $175 |
| Residential | $150 | $100 |
TH tags exported. Screen reader announces column context with every cell.
Screen reader without header row:
"Row 1: Fee Type. Standard. Reduced. Row 2: Commercial. 250. 175." [no column context — user cannot tell what 250 refers to]
Screen reader with designated header row:
"Fee Type: Commercial. Standard Rate: $250. Reduced Rate: $175." [full column context with every cell]
How to designate a header row in Word
Click anywhere in the top row, then go to Table Design tab and check Header Row. Then right-click the row, select Table Properties, go to the Row tab, and check Repeat as header row at the top of each page. Both steps required for full tag export.
PDF Accessibility Checklist (Quick Version)
- Use heading styles (not manual formatting)
- Add alt text to images
- Set document language
- Use table headers properly
- Export with accessibility tags enabled
- Run an accessibility checker
- Verify reading order
- Test with a screen reader
Part 1: How to Create an Accessible PDF from Microsoft Word
Microsoft Word is the most common source application for government documents. When you follow these steps before exporting to PDF, the resulting file will have the structural foundation required for accessibility. You will still need to check the output — covered in Part 4 — but this process eliminates the most common structural failures.
Step 1: Use Built-In Heading Styles
The most important thing you can do for document accessibility in Word is use the built-in heading styles rather than formatting text manually.
What most people do: Type a section heading, select the text, make it bold, increase the font size to 14 or 16 points.
Why this fails: Bold large text looks like a heading visually but has no structural meaning. When exported to PDF, screen readers read it as a paragraph of bold text — not a navigable heading.
What to do instead: Select the heading text and apply a Heading style from the Styles panel on the Home tab.
- Document title → Heading 1
- Major section headers → Heading 2
- Sub-sections → Heading 3
- Content under sub-sections → Normal
Before (inaccessible):
[Bold, 16pt text]: "Section 3: Application Requirements"
[Normal text]: "All applicants must submit the following..."
Screen reader announces: "Section 3 Application Requirements" — reads as body text, not a navigable landmark.
After (accessible):
[Heading 2 style]: "Section 3: Application Requirements"
[Normal style]: "All applicants must submit the following..."
Screen reader announces: "Heading level 2: Section 3 Application Requirements" — user can navigate directly to this section using heading navigation.
Step 2: Add Alternative Text to Every Informational Image
Any image in your document that conveys information needs alternative text — a written description that tells screen reader users what the image communicates.
To add alt text in Word: right-click the image, select "Edit Alt Text," and type a description in the alt text panel.
For decorative images — images that add visual interest but convey no information — check the "Mark as decorative" checkbox instead of writing a description. Screen readers will skip these entirely.
Alt text examples:
Bad alt text: "chart.png" Bad alt text: "Image of chart" Bad alt text: "Chart showing data"
Good alt text for a bar chart: "Bar chart showing permit application volume by month in 2024. January: 142. February: 98. March: 167. Peak volume in October: 312."
Good alt text for a map: "Map showing the downtown rezoning area bounded by Main Street to the north, 5th Avenue to the east, Commerce Street to the south, and Highway 34 to the west."
Good alt text for a photo: "Mayor Johnson signing the revised accessibility ordinance at city hall on March 15, 2026."
The principle: describe what the image communicates, not what it looks like.
Step 3: Create Accessible Tables
Tables in Word need header rows properly designated so screen readers can announce the relationship between data cells and their column or row headers.
To set a header row in Word: click anywhere in the top row of the table, go to the Table Design tab, and check "Header Row." Then right-click the row, select "Table Properties," go to the "Row" tab, and check "Repeat as header row at the top of each page."
Avoid using tables for layout. If you are using a table to position text in columns on a page — not to display data relationships — replace it with columns or text boxes. Tables used for layout create reading order confusion for screen readers.
Before (inaccessible table): A fee schedule table with four columns — Fee Type, Standard Rate, Reduced Rate, Waiver Eligible — but no header row designated. Screen reader announces each cell as: "Edit. Commercial Permit. Edit. 250. Edit. 175. Edit. Yes." — no column context provided.
After (accessible table): Same table with the header row designated. Screen reader announces: "Fee Type: Commercial Permit. Standard Rate: 250. Reduced Rate: 175. Waiver Eligible: Yes." — full context with every data cell.
Step 4: Write Descriptive Link Text
Links in your document should describe where they go, not just say "click here" or "learn more."
Inaccessible: "For permit requirements, click here." Accessible: "Review the commercial permit requirements on the Planning Department website."
Screen reader users frequently navigate documents by jumping between links. A list of links that all say "click here" is completely uninformative. A list of links with descriptive text tells the user exactly what each link leads to before they follow it.
Step 5: Set the Document Language
In Word: go to File > Options > Language, and confirm the editing language is set correctly. For documents in multiple languages, select the text in each language and set the language for that section through the Review tab > Language > Set Proofing Language.
This tells screen readers which language pronunciation profile to use. A document with no language set may be read with incorrect pronunciation that makes it incomprehensible.
Step 6: Run the Word Accessibility Checker Before Exporting
Before you export to PDF, run Word's built-in accessibility checker: go to Review > Check Accessibility. The checker identifies common issues including missing alt text, tables without header rows, missing document title, and other structural problems.
Fix every error and address every warning before proceeding. The checker is not comprehensive — it will not catch every accessibility issue — but it catches the most common structural failures.
Step 7: Export to PDF Using the Correct Settings
This is the step where most accessible Word documents become inaccessible PDFs. Using the wrong export method discards all the accessibility structure you built.
Do not use: Print > Microsoft Print to PDF. This creates a flat PDF with no accessibility tags. All your heading structure, alt text, and table headers are lost.
Do not use: Save a Copy as PDF without checking the options. Default settings vary by Word version and may not include tags.
The correct method:
- Go to File > Save As (or Export)
- Select PDF as the file format
- Click "More Options" (not just Save)
- In the Save As dialog, click "Options"
- Check "Document structure tags for accessibility"
- Check "Document properties"
- Check "Bitmap text when fonts may not be embedded" — leave unchecked
- Click OK and save
Alternatively, go to File > Export > Create PDF/XPS, click "Options," and confirm "Document structure tags for accessibility" is checked before publishing.
Part 2: How to Create an Accessible PDF from Google Docs
Google Docs has more limited native accessibility export capabilities than Word, but following these steps produces a better baseline than an unoptimized export.
Step 1: Use Heading Styles
Same principle as Word. Use the Styles dropdown in the toolbar — not manual bold formatting — to apply Heading 1, Heading 2, and Heading 3 to section titles.
Step 2: Add Alt Text to Images
Right-click any image in the document, select "Alt text," and add a description in the Description field. Leave the Title field empty — screen readers read the Description field.
Step 3: Export Settings
Go to File > Download > PDF Document (.pdf).
Google Docs will export with basic tag structure if you have used heading styles and alt text. The output is not as fully tagged as a properly configured Word export, but it will include heading navigation and image alternatives.
After downloading, open the PDF in Adobe Acrobat and run the accessibility checker (covered in Part 4) to identify any gaps the Google export did not address.
Part 3: How to Create an Accessible PDF from Adobe InDesign
InDesign is commonly used for designed documents — annual reports, program guides, regulatory publications — and requires specific export settings to produce accessible PDFs.
Step 1: Set Up the Article Panel for Reading Order
InDesign uses the Articles panel to define reading order — the sequence in which screen readers will navigate through content. Without this, InDesign exports content in the order it was placed on the page, which often does not match logical reading order.
Go to Window > Articles to open the Articles panel. Create an article, then drag all content frames into the article in the correct reading order. For a two-column layout, drag the left column frames before the right column frames.
Step 2: Add Alt Text to Images and Graphics
Select any placed image or graphic. Go to Object > Object Export Options > Alt Text tab. Select "Custom" from the Alt Text Source dropdown and type the alternative text description.
Step 3: Set Paragraph Styles to Map to PDF Tags
In InDesign, paragraph styles control how content is tagged in the exported PDF. Open the Paragraph Style Options for each style (double-click the style in the Paragraph Styles panel), go to the Export Tagging section, and set the PDF tag for each style:
- Document title style → H1
- Major section headers → H2
- Sub-section headers → H3
- Body text → P
- Caption text → Caption (or P if Caption is not available)
Step 4: Export with Accessibility Settings
Go to File > Export, select Adobe PDF (Print) or Adobe PDF (Interactive) as the format, and in the Export Adobe PDF dialog:
- Under General: check "Create Tagged PDF"
- Under Advanced: check "Use Document Structure for Tab Order"
Part 4: How to Check a PDF for Accessibility Before Publishing (WCAG Checklist)
After creating or receiving a PDF, run these checks before publishing it publicly.
Check 1: Run the Adobe Acrobat Accessibility Checker
If you have Adobe Acrobat Pro (not just the free Acrobat Reader): open the PDF, go to Tools > Accessibility > Accessibility Check. Run a full check and review the results panel.
The checker evaluates the document against PDF/UA and WCAG criteria and flags issues in categories including: document structure, page content, tables, lists, headings, and forms.
Fix all failures before publishing. Address warnings where possible.
If you do not have Adobe Acrobat Pro: Use the free PAC 2021 (PDF Accessibility Checker), available as a free download from the PDF/UA Foundation. It provides similar functionality for teams without Acrobat Pro licenses.
Check 2: Test the Reading Order
In Adobe Acrobat: go to View > Show/Hide > Navigation Panes > Order. This panel shows the reading order the screen reader will follow. Confirm it matches the logical reading sequence of the document — top to bottom, left to right for single-column layouts, down each column in sequence for multi-column layouts.
If the reading order is wrong, it needs to be corrected either in the source application (preferred) or through the Order panel in Acrobat.
Check 3: Check the Tag Tree
In Adobe Acrobat: open the Tags panel (View > Show/Hide > Navigation Panes > Tags). The tag tree shows the structural hierarchy of the document.
Look for:
- An H1 at the document title level
- H2 and H3 for sections and subsections in logical hierarchy
- P tags for body text paragraphs
- Table tags with TH (table header) and TD (table data) cells correctly nested
- Figure tags with Alt attributes for images
- No content sitting outside the tag tree (this is "artifact" content — typically decorative — but verify it is correct)
Check 4: Verify Form Field Labels (for fillable forms)
If the document is a fillable PDF form, open each form field in Acrobat's form editor and confirm that every field has a tooltip that matches its visible label. The tooltip is what screen readers announce when a user focuses on the field.
Before (inaccessible): Field tooltip: "Text1" After (accessible): Field tooltip: "First Name (required)"
Check 5: Quick Screen Reader Test
If you have NVDA installed (free download), open the PDF in Adobe Acrobat Reader and press NVDA + F7 to open the elements list. Verify that headings appear in logical hierarchy. Tab through any form fields and confirm each one is announced with its label. Read through a section of body text to confirm the reading order matches what you see visually.
This takes about five minutes and catches issues the automated checker misses.
Part 5: How to Remediate an Existing Inaccessible PDF
For the scanned and untagged documents already in your agency's document library, here is the remediation process based on document type.
Remediating Scanned PDFs
Step 1: Run OCR (Optical Character Recognition) In Adobe Acrobat Pro: open the scanned PDF, go to Tools > Scan and OCR > Recognize Text > In This File. Select "Searchable Image (Exact)" as the output style. This adds a text layer beneath the image.
Step 2: Add Accessibility Tags After OCR, the document has text but no structure. Go to Tools > Accessibility > Autotag Document. Acrobat will attempt to automatically tag the document structure. This produces a starting point, not a finished product — the autotag output requires manual review and correction.
Step 3: Review and Correct the Tag Structure Open the Tags panel and review the automatically generated structure. Common autotag errors include: body text tagged as headings, headings tagged as body text, table cells not correctly associated with headers, and images tagged as decorative when they contain information. Correct each error manually.
Step 4: Verify Reading Order Open the Order panel and confirm the reading order is correct. Reorder elements as needed.
Step 5: Run the Accessibility Checker and Address All Failures
Remediating Untagged Exported PDFs
If you still have the source file (Word, InDesign, etc.), the most efficient remediation is to return to the source, apply accessibility settings there, and re-export following the steps in Parts 1 through 3. This is always preferable to remediating in Acrobat.
If the source file is not available: use Tools > Accessibility > Autotag Document in Acrobat, then follow Steps 3 through 5 above.
The Pre-Upload Accessibility Checklist
Before uploading any PDF to a public-facing government website, run through this checklist. It takes about five minutes for a document you created with accessibility in mind and somewhat longer for a document you are reviewing for the first time.
Document Structure
- Document has a defined title in File > Properties > Description
- Language is set correctly
- Heading styles are used (not manual bold formatting) in a logical hierarchy
- No heading levels are skipped (H1 to H3 without an H2, for example)
Images and Graphics
- Every informational image has alt text describing what it communicates
- Decorative images are marked as artifacts or have empty alt text
- Charts and data visualizations have alt text that conveys the data
Tables
- All data tables have a designated header row
- Tables are not used for page layout
- Complex tables with both row and column headers have both properly designated
Links
- All hyperlinks have descriptive text explaining where they go
- No links say "click here" or "read more" without context
Forms (if applicable)
- Every form field has a tooltip that matches its visible label
- Required fields are identified both visually and programmatically
- Error messages are clear and specific
Technical Checks
- Adobe Acrobat accessibility checker shows no failures
- Reading order verified in the Order panel
- Document passes a basic screen reader spot check
The Going-Forward Standard
Individual document remediation is necessary for your existing library. But the more important change is establishing a standard that prevents inaccessible documents from being created in the first place.
The going-forward standard for your agency should be simple enough that every staff member who creates documents can follow it:
Use heading styles, not manual formatting. Add alt text to every informational image before exporting. Check the accessibility checker in Word before saving to PDF. Export using the correct settings with accessibility tags enabled. Check the PDF in Acrobat or PAC before uploading.
That five-step standard, applied consistently, eliminates the vast majority of PDF accessibility failures at the point of creation — before they become part of the public document library that needs remediation.
Put it on a laminated card next to every computer where staff create public documents. Make it part of new employee onboarding. Document training completion. The standard only works if people follow it, and people only follow it if it is simple, visible, and expected.
Related:
Good Faith Compliance Explained
FAQ: PDF Accessibility for Government Agencies
What makes a PDF accessible under WCAG 2.1 AA? An accessible PDF has a logical tag structure that defines document hierarchy for screen readers, a correct reading order that matches the visual flow of the document, alternative text for all informational images, properly associated table headers, descriptive link text, programmatically labeled form fields, and a defined document language. These elements allow screen reader software to interpret and navigate the document correctly. A PDF that looks correct visually but lacks this underlying structure is completely inaccessible to users who rely on screen readers.
Are scanned PDFs accessible? No. A scanned PDF is a flat image with no text layer and no structural information. Screen readers see nothing in a scanned PDF regardless of how clearly the text appears visually. Scanned documents require OCR processing to add a text layer, followed by full accessibility tagging to add document structure. This makes scanned PDFs the most time-intensive category to remediate and the most important to address in agencies with large historical document libraries.
What is the fastest way to make a PDF accessible? The fastest path to an accessible PDF is to create it correctly from the source application using heading styles, alt text, and the correct export settings — rather than remediating the PDF after the fact. A Word document created with proper heading styles and exported with accessibility tags enabled takes about the same amount of time as creating the document without those settings. Remediating an untagged or scanned PDF in Adobe Acrobat takes significantly longer. Investment in accessible document creation training for staff who create documents regularly is the most cost-efficient approach to PDF accessibility at scale.
Does Google Docs export accessible PDFs? Google Docs exports PDFs with basic structural tags if heading styles have been applied and alt text has been added to images. The output is less fully tagged than a properly configured Word export and typically requires review and remediation in Adobe Acrobat Pro before it meets WCAG 2.1 AA requirements. For high-visibility documents, use Word with the correct export settings or create the document in Adobe InDesign with proper export configuration. Google Docs exports are acceptable for lower-visibility documents when reviewed with an accessibility checker after export.
Do we need Adobe Acrobat Pro to make PDFs accessible? Adobe Acrobat Pro is the most capable tool for PDF accessibility checking and remediation, but it is not the only option. The free PAC 2021 (PDF Accessibility Checker) provides comprehensive automated accessibility checking without a cost. NVDA, a free screen reader, can be used for manual testing. Many accessibility issues can be eliminated at the source application level — in Word, Google Docs, or InDesign — before the PDF is created, reducing the need for Acrobat remediation. For agencies with large document remediation programs, Acrobat Pro licenses for staff who manage document workflows are a worthwhile investment.
How do we handle the existing PDF backlog in our document library? Start with a document inventory that classifies every publicly accessible PDF by type — active service forms, meeting documents, regulatory publications, archival content — and by accessibility status. Prioritize remediation starting with active service forms, current meeting documents, public notices, and any document required for public participation. These represent the highest-impact accessibility failures and the highest legal exposure. Historical archival documents can be addressed on a longer timeline. Establish a going-forward accessible document creation standard immediately so the backlog stops growing while you work through it.