When people talk about website accessibility, the conversation usually centers on web pages: color contrast, heading structure, keyboard navigation, alt text on images.
All important. All worth getting right.
However, there’s a category of content that shows up on websites constantly and gets skipped in almost every accessibility audit: PDFs.
Annual reports. Program flyers. Intake forms. Policy documents. Grant summaries.
If you serve a nonprofit, government agency, or advocacy organization, your website is almost certainly linking to PDFs. And if those PDFs weren’t built with accessibility in mind, you’ve got a gap that a WAVE or AMP scan won’t catch.
Whether you’re creating documents in Microsoft Word, designing in Adobe InDesign, or cleaning things up in Acrobat after the fact, here’s what you need to know.
The Legal Layer: ADA Title II and Your PDFs
If you work for or with a state or local government agency (or you are one) PDF accessibility isn’t just a best practice. It’s a legal requirement with a deadline.
In April 2024, the Department of Justice published a final rule under Title II of the Americans with Disabilities Act requiring state and local governments to make their web content and mobile apps conform to WCAG 2.1 Level AA. And the rule is explicit: “electronic documents” are defined as web content that includes PDF, word processor, presentation, and spreadsheet file formats. Your PDFs aren’t a footnote to the rule. They’re covered by it.
The current compliance dates (because this has shifted):
In April 2026, the DOJ issued an Interim Final Rule extending the compliance deadlines. Public entities with a total population of 50,000 or more now have until April 26, 2027. Public entities with a population under 50,000, or any special district government, have until April 26, 2028.
If you serve state agencies, county offices, councils, or any government-adjacent organization, those are the dates that matter.
What the rule covers… and what it doesn’t:
The extension gave organizations more time, but it didn’t change the scope of what’s required. A few specifics worth knowing:
Documents posted after your compliance date have no grace period. If a town posts a PowerPoint presentation for an upcoming council meeting after its compliance date, that presentation would not fall under any exception and would need to meet WCAG 2.1 Level AA. Similarly, if a city updates a document that was originally posted in 2020 (even just to add new contact information) that updated document loses its exception status and must comply.
Documents used to access services can’t hide behind an age exception. Any digital documents people use to apply for, gain access to, or take part in your services, programs, or activities must be accessible, regardless of when they were originally posted. That intake form you uploaded three years ago and never touched? If people are using it to access services today, it needs to be accessible.
Pre-existing documents may qualify for an exception, but only if they were posted before the compliance date, haven’t been updated, are kept only for reference or recordkeeping, and aren’t being actively used to access services. The DOJ recognized the difficulty in remediating older documents like PDFs and created a limited exception for them, but it’s narrow, and it doesn’t cover the documents most organizations rely on daily.
A note for nonprofits and private organizations:
ADA Title II applies specifically to state and local government entities. If your organization is a nonprofit or private business, Title II doesn’t directly govern you, though Title III of the ADA covers places of public accommodation and has its own active litigation landscape (which I covered in an earlier post in this series).
Even outside of the legal requirement, accessible PDFs are simply good practice. Your audience includes people who rely on screen readers, have low vision, or use keyboard-only navigation… and an inaccessible PDF shuts them out completely.
The compliance clock is running. And if you’re producing PDFs for government clients (think: annual reports, program guides, intake forms, policy documents) you’re producing documents that fall under this rule. Getting the workflow right now is far less painful than remediating a backlog later.
Why PDFs Are a Different Problem
A tagged PDF and an untagged PDF can look absolutely identical on screen. The difference lives underneath the visual layer, in the structure that screen readers and other assistive technologies rely on to make sense of the content.
Tags are digital labels that organize content in a PDF. They give assistive technologies the information they need to interpret the document: identifying paragraphs, tables, figures, and headings. Tags are the only reason PDF documents have internal structure, and that structure is the only way assistive technology users can reliably access the information inside.
Without tags, a screen reader may attempt to read the document anyway, but the results are often scrambled, skipped, or just plain wrong. A two-column layout might read left-to-right across both columns instead of down each one. A table might be read as a string of unrelated text. A decorative image might be announced as “graphic” with no description and no way to skip it.
The fix is not difficult, but it does have to start in the right place.
Start in Word: Build Accessibility In, Don’t Tag It Later
If you’re creating standard documents (reports, policy summaries, program guides) Microsoft Word is likely your starting point. Good news: building accessible authoring practices into your Word document means that versions exported to other formats retain most, if not all, accessibility features
The most important thing to understand is this: do not use the “Print to PDF” function. It creates a PDF that lacks tags — no heading information, no alternative text, no logical document structure. These are the kinds of barriers that make a document genuinely unusable for someone relying on a screen reader.
Before you export anything, build the structure correctly inside Word:
- Use real heading styles (Heading 1, Heading 2, etc.) from the Styles panel — not just bold text that looks like a heading. Word now correctly exports the Title style as an H1 tag when you use File > Save As > PDF. One important caveat: if you use the Acrobat toolbar plugin to export instead, Word won’t apply that H1 tag.
- Add alt text to images.
- Add meaningful link text. (Example: Visit nth degree media & designs’ website. Not “click here”).
- Use Word’s built-in list tools rather than manually typed dashes or asterisks.
- If you have data tables, make sure they have proper header rows.
Then, before you export: run Word’s built-in Accessibility Checker under File > Info. Addressing accessibility issues in the Word file is much easier than correcting them after the document has been converted to PDF.
When you’re ready to export, select “Best for electronic distribution and accessibility” in the export format options. That’s the setting that carries your document’s structure into the PDF.
Designing in InDesign: Structure Has to Be Intentional
InDesign produces beautiful documents. Much to my chagrin as a designer, it also produces some of the most inaccessible PDFs on the internet. Not because the tool can’t do accessibility, but because the visual design workflow and the accessibility workflow require deliberate overlap.
An accessible PDF includes structure and meaning that define how content should be interpreted, not just how it looks. InDesign supports an accessibility-first workflow by building structure directly into the source document, which reduces the need for post-export fixes. [Source: Adobe]
Here’s where most InDesign documents go wrong:
Paragraph Styles aren’t mapped to export tags. You may have set up a beautiful H1 style for your document title, but unless you’ve told InDesign what that style maps to in the PDF, it exports as a generic paragraph tag. Edit each Paragraph Style, select the Export Tagging tab, and set the appropriate PDF tag: headings get H1 through H6, body text gets P, and decorative content that should be skipped by assistive technology gets set to Artifact.
Reading order is wrong. In a multi-column or complex layout, InDesign doesn’t automatically know what order the content should be read in. Use the Articles panel to define reading order: open Window > Articles, check “Use for Tagging Order in Tagged PDF,” then drag and drop your content elements into the Articles panel in the order they should be read.
Images need alt text or need to be marked decorative. Right-click on an image, select Object Export Options, and go to the Alt Text tab. For meaningful images, set Alt Text Source to Custom and write a description. For purely decorative images, set the source to Decorative Image (no Alt Text) so assistive technology skips it. Honestly, I would include alt text even if it is a decorative element.
Tables need header rows. Avoid merging cells. Highlight your first table row, right-click, and select Convert to Header Rows.
When you’re ready to export: go to File > Export, select Adobe PDF (Print), and make sure “Create Tagged PDF” and “Use Structure for Tab Order” are both checked.
Designing in Canva: More Capable Than You Might Think… But With Limits
Canva has become the go-to design tool for small nonprofits, government communication teams, and small business owners who need polished documents without a full Adobe Creative Cloud subscription. And Canva has actually added meaningful accessibility features in recent years… enough to be worth doing correctly, as long as you understand what it can and can’t do.
Text semantics: Don’t skip this step.
By default, Canva assigns heading semantics automatically based on visual hierarchy, things like font size and placement. But you can, and should, override this manually. Don’t rely on Canva to guess correctly.
Go to File > Accessibility > Edit text semantics. Every text element in your design will appear in a list, and you can assign each one the correct tag: Heading 1 for your main title, Heading 2 for section headings, and so on down through subheadings and body paragraphs.
Choose heading levels based on how the content is organized in the document, not the visual appearance of the text. Screen reader users often navigate documents by headings, and without a proper heading structure, the document can be difficult to understand or navigate.
One important export gotcha: make sure the Flatten PDF checkbox is unchecked when you export. Flattening removes all accessibility tags. Export as PDF Standard, not a flattened file.
Reading order: Layers matter more than you think.
In Canva, reading order is controlled through the Layers panel. Content at the bottom of the layer stack is read first. To set your reading order, go to Position, view your layers, and arrange them in the sequence you want a screen reader to follow. Then select “Match reading order to layers” before downloading.
This is where Canva gets genuinely tricky. For a simple, linear document, this may not matter much — but for a report with charts, callout boxes, and multi-column layouts, the exported PDF can behave unpredictably with assistive technology. The layer-based approach is manageable on a single-page flyer. On a multi-page annual report with mixed content, it takes significant time and may still not produce a clean result.
What Canva’s built-in Accessibility Checker actually covers
Canva’s checker tests three things: typography, color contrast, and alt text. That’s it. It will not tell you if your reading order is wrong, if your headings are tagged incorrectly, or if your tables are readable by a screen reader. A document can pass Canva’s accessibility check and still have serious structural problems that a screen reader user will hit immediately.
Canva is not yet capable of producing a fully accessible PDF document per WCAG standards. That’s not a knock on the tool… it’s just the reality of where it sits in the workflow. Think of Canva as a strong starting point, not a finishing line.
The honest bottom line on Canva
Canva PDFs aren’t PDF/UA or WCAG compliant. You will need to check for accessibility and manually remediate your PDFs before distribution. Use the text semantics tool, manage your layer order carefully, add alt text to every meaningful image (or mark decorative images as decorative), and then — just like Word and InDesign — open the exported PDF in Adobe Acrobat Pro and run the Accessibility Checker before it goes live.
One additional heads-up: there’s a known issue where built-in browser PDF readers and VoiceOver may not read exported Canva PDFs correctly when opened in macOS Preview or Safari, even when tags appear correctly in Adobe Acrobat. For the most reliable screen reader experience, open exported PDFs in Adobe Acrobat.
For simple designs (a one-page flyer, an event announcement, a social graphic with a downloadable version) Canva with careful text semantics and a final Acrobat check can get you close. For complex, multi-page documents with tables, charts, and multi-column layouts, Word or InDesign will give you more reliable results and less remediation time on the back end.
Using Adobe Acrobat: The Final Check (and Sometimes the Fix)
Even a well-built Word or InDesign document benefits from a final review in Adobe Acrobat Pro. And if you’re working with a PDF someone handed you — or one that was exported without any of the steps above — Acrobat is where remediation happens.
The Accessibility Checker in Acrobat Pro is a good place to start reviewing and fixing PDF accessibility issues. To run it: select All Tools > Prepare for Accessibility > Check for Accessibility. Make sure all checking options are selected before running. The checker breaks results into seven categories: Document, Page Content, Forms, Alternative Text, Tables, Lists, and Headings.
A few things the checker will flag that you’ll need to address manually:
Reading order. Adobe has no way of knowing if your document is in a logical reading order — you have to check for yourself. Use the Fix Reading Order tool under All Tools > Prepare for Accessibility. Open the Show Order panel to see the sequence in which content will be read, and select individual elements to see their order highlighted in the document.
Document title. The title field in your PDF’s metadata should reflect the document’s actual name, not the filename. Acrobat’s checker will flag this if it’s missing.
Color contrast. The Accessibility Checker will flag color contrast every time you run it — because Acrobat can’t evaluate it automatically. You have to check for yourself, using an external tool. (WebAIM’s Contrast Checker is a good one.)
One important mindset shift for anyone who does this regularly: the Reading Order tool is intended for repairing PDFs that were tagged using Acrobat, not for repairing PDFs that were tagged during conversion from an authoring application. Whenever possible, return to the source file and fix accessibility there. Repairing the original file ensures you don’t have to repeatedly touchup future versions of the PDF in Acrobat. Adobe
In other words: Acrobat is a finishing tool and a safety net… not a substitute for doing the work upstream.
The Practical Takeaway
If your organization regularly publishes PDFs (forms, reports, newsletters, guides) here’s the short version:
Start in Word or InDesign, build the structure correctly from the beginning, export using the right settings, and run Acrobat’s Accessibility Checker on the final file before it goes live. That sequence catches the vast majority of issues before anyone with a screen reader ever encounters them.
PDFs aren’t going away. Making them accessible isn’t optional under ADA Title II… and more importantly, it’s just the right thing to do for the people trying to use your content.
If you’re not sure where your organization’s PDFs stand, that’s a conversation worth having. It’s one of the first things I look at when I’m auditing a client’s site.
ES 
EN