The PDF Problem Nobody on Your Team Has Time to Fix
Why exported documents fail accessibility checks, and where to start with your backlog.
Every organization I have worked with on accessibility has the same moment of reckoning. Someone runs an accessibility checker on a document the team has been posting publicly for years and sees a report with dozens of failures.
Course catalogs. Annual impact reports. Grant application guides. Program brochures. Financial disclosures. These documents exist in the hundreds at most colleges, universities, and nonprofits. They were formatted carefully, exported to PDF, and posted to the website. Almost none of them are accessible.
Not because the teams who created them did not care. Because nobody told them that exporting a well-formatted document does not produce an accessible PDF.
Why exporting isn’t enough
When you export a Word document or an InDesign file to PDF, what transfers is the visual presentation. What does not reliably transfer is the underlying structure that assistive technology depends on to interpret the file.
Headings that look like headings may have no structure a screen reader can detect. Images that had alt text in the source file may arrive without it. A table that reads clearly on screen may give a screen reader no information about which row or column each cell belongs to.
A document can look perfectly formatted and be completely unusable for someone relying on a screen reader, a keyboard, or other assistive technology. The only way to know is to check. Adobe Acrobat Pro and the free PAC (PDF Accessibility Checker) will flag many problems, and testing with a screen reader shows you what a real reader experiences.
That gap between how a document looks and how it is built is where most organizations' PDF problem lives. And it is larger than most teams realize until they start looking.
Why this is a compliance problem, not just a web problem
A PDF posted publicly is part of your website, and accessibility laws treat it that way. Which rules apply depends on who you are:
- Public colleges, universities, and state and local government entities fall under Title II of the ADA. The updated Title II rule sets a clear technical standard, WCAG 2.1 AA, for web content and documents.
- Private colleges, universities, and nonprofits open to the public are generally covered by Title III of the ADA.
- Organizations that receive federal funding also have obligations under Section 504 of the Rehabilitation Act.
The Title II rule does include some exceptions, including one for documents posted before the compliance date. But that exception does not apply to documents people still use to apply for, access, or participate in your programs and services. Enrollment forms, financial aid guides, application instructions, and program requirements are exactly the documents that stay in scope.
For students, the stakes are practical. If a student using a screen reader cannot navigate your course catalog, that is a barrier to information they need to enroll, plan, and finish their degree. For nonprofits, the same is true for anyone trying to apply for a program or understand how to get help.
The document backlog is almost always the largest unaddressed gap I find during accessibility audits. It is also one of the most fixable, once the process is understood and resourced.
See how accessibility audits work
(This is a general overview, not legal advice. Your counsel can tell you exactly which rules apply to your organization. Last reviewed October 12, 2026.)
What remediation actually involves
PDF remediation is the process of building and correcting the tag structure underneath what a reader sees on screen. Tags are the invisible layer that tells assistive technology what each element is: a heading, a paragraph, a list item, a table cell, an image. Without correct tags, a screen reader processes the document as a flat, unordered stream. It may read columns out of sequence, miss images entirely, or present table data with no context.
For a simple single-column text document, remediation is relatively contained. For a multi-column publication, a table-heavy report, or a document originally designed for print, it is a different order of work entirely.
The most common failures fall into four categories:
- Missing or incorrect tag structure
- Images without alt text
- Tables with no header associations
- Missing document properties, like a defined title and language
Each has its own remediation path. None of them are reliably fixed by re-exporting from the source document.
Some documents need significant extra work before remediation can even start. A document that was printed and scanned exists as an image, with no text a screen reader can access. It has to go through OCR conversion first, and the results always need human review. Forms, complex overlapping layouts, and intricate print designs fall into the same higher-complexity category.
What teams ask most about PDF accessibility
These are the questions I hear most often from registrar offices, communications teams, and compliance staff.
Can I make a PDF accessible just by running Adobe Acrobat’s accessibility checker?
No. The checker finds problems, and Acrobat can fix a few simple ones, like a missing title or language. But the structure underneath, which is what a screen reader depends on, needs a person who understands how assistive technology reads a document. The checker is the starting point, not the solution.
Does fixing the Word document and re-exporting fix the PDF?
Sometimes, for simple documents. A well-built Word file carries more structure into the PDF than a poorly built one, so it is worth doing as a first step. But complex layouts, tables, and images almost always need manual correction in Acrobat Pro after export.
How long does PDF remediation take?
It depends on complexity, not page count. A short, simple text document can be done in under an hour. A long catalog with tables, images, and multi-column layouts can take many hours or more. Scanned documents that need OCR take longer still.
Which documents should we prioritize?
Start with the documents people need to access your services: enrollment forms, financial aid guides, program requirements, application instructions, and anything linked from your homepage or key program pages. High-traffic documents with high stakes for the reader come first.
Stop the backlog from growing
The backlog is a one-time problem. What creates it is ongoing: people producing documents without knowing that accessibility is part of the job.
Most registrar staff, program coordinators, and communications team members have never been shown what makes a document accessible before it is exported. They are formatting documents and posting them in good faith. The gap is knowledge, not effort.
When the people who create documents understand how to build accessible source files, what the export does and does not carry through, and what to check before posting, the number of new inaccessible documents drops significantly. Remediation becomes manageable instead of constant.
Training is not a replacement for fixing your existing backlog. It is what keeps the backlog from growing while you work through what is already there.
Moving forward
The documents already on your site will not fix themselves. But the process for addressing them is knowable, even when it is not simple. The organizations that get ahead of this treat it as ongoing practice, not a one-time project.
If your team has never looked at your document backlog from an accessibility standpoint, now is the time. What you find will tell you what to do next.
If you’d like help sizing up your document backlog, let’s talk.
Book a time to talk
Katherine Delaney is a Boston-area digital strategist working with nonprofits, universities, schools, and healthcare organizations on storytelling, website content, and accessibility.