PDFs are among the most commonly published file types on government and education websites — and among the most frequently inaccessible. Here’s what’s at stake, where the problem starts, and how a simple pre-export checklist can prevent most errors before they happen.
The hidden accessibility gap in your file library
If your organization publishes PDFs to a public-facing website — annual reports, newsletters, meeting agendas, handbooks, grant documents, forms — there’s a reasonable chance that many of those files are inaccessible to users who rely on screen readers, keyboard navigation, or other assistive technologies.
This isn’t a failure of intention. It’s a failure of workflow. Most staff who create documents have never been taught that saving a Word file to PDF the wrong way, skipping a Title field, or forgetting to add alt text to an image can effectively lock a portion of your audience out of that content entirely.
The good news: the majority of PDF accessibility errors are preventable at the source, before a file is ever exported, with a checklist and a few changed habits.
Why this matters now more than ever
PDF accessibility has been a legal requirement for federal agencies under Section 508 of the Rehabilitation Act for decades. But for state and local governments, K-12 schools, and higher education institutions, enforcement has historically been inconsistent.
That landscape is changing. In April 2024, the U.S. Department of Justice issued a final rule under Title II of the Americans with Disabilities Act establishing specific, enforceable web content accessibility standards for state and local governments. Under this rule, web content — including PDFs published on government and public education websites — must conform to WCAG 2.1 Level AA standards.
Compliance deadlines are staggered based on population size. Under a DOJ Interim Final Rule issued April 20, 2026, most West Virginia entities with populations of 50,000 or more must comply by April 26, 2027, while smaller entities and special districts have until April 26, 2028.*
For higher education, the Department of Education’s Office for Civil Rights has significantly increased the number of accessibility complaints it investigates, and resolution agreements routinely require institutions to remediate inaccessible documents and audit their digital content libraries.
Important: Inaccessible PDFs are not a minor formatting concern — they are a civil rights compliance issue. Organizations that publish documents their users cannot read may face formal complaints, federal investigations, and remediation requirements that are far more costly than prevention.
What makes a PDF inaccessible?
An accessible PDF is more than readable text. It has a documented structure that assistive technology can interpret: headings that define document hierarchy, tagged content that tells screen readers what each element is, alt text that describes images, a title that is announced when the file opens, and a declared language so pronunciation rules apply correctly.
When those elements are missing, users of screen readers experience the document as a stream of undifferentiated text — or worse, silence — with no way to navigate to a section, understand a chart, or even know what document they’ve opened.
The most common errors seen in PDF accessibility scans fall into a handful of categories:
| Error | What users experience | Typical cause |
|---|---|---|
| No document title | Screen reader announces the filename (“newsletter_fall21_v2.pdf”) instead of a meaningful title | Title field left blank before export |
| Language not set | Screen reader mispronounces words or applies wrong language rules | Never set in document properties |
| Missing alt text on images | Images are skipped or announced as “unlabeled graphic” | Alt text not added before export; or exported via Print instead of Save As |
| Untagged content | Decorative elements read aloud as noise; structure is unclear | Exported from Publisher, Canva, or via “Print to PDF” |
| No heading structure | Users cannot navigate by heading; long documents must be read start to finish | Headings styled manually instead of using Heading styles |
| Heading levels skipped | Navigation is confusing; heading order doesn’t match document logic | Heading styles applied inconsistently |
The workflow problem
Most PDF accessibility failures don’t happen because someone made a careless decision. They happen because the accessibility-critical steps in the document creation process are invisible to people who haven’t been specifically trained to look for them.
Consider a typical document workflow: a staff member drafts a newsletter in Microsoft Word, formats headings by selecting text and making it big and bold, drops in a few photos, then goes to File → Print → Save as PDF. The resulting file looks exactly right on screen. But it has no structural tags, no alt text, no title, and potentially no reading order — because the Print path destroys all of that information on the way out.
That same document, exported via File → Save As → PDF with the accessibility options checked, with heading styles applied and a title filled in, would be dramatically more accessible — and the extra time required is less than five minutes.
The common (broken) workflow: Draft document → format manually → File → Print → Save as PDF → upload to website
The accessible workflow: Fill in Title → use Heading styles → add alt text → File → Save As → PDF (with accessibility options checked) → upload to website
The difference between these two workflows is not skill — it’s awareness. Staff who know what to do will do it. The challenge is building that knowledge systematically across an organization.
How a pre-export checklist changes the outcome
A checklist does two things that training alone cannot: it puts the right questions in front of the right person at the right moment, and it makes the invisible visible. A staff member who doesn’t think about alt text in their day-to-day work will think about it when “Did I add alt text to all meaningful images?” is the third item on a list they’re holding before they hit Export.
In WVNET’s experience supporting web accessibility compliance across K-12, higher education, and state agency clients, the shift from ad-hoc document creation to checklist-guided workflows consistently reduces PDF accessibility errors — not to zero immediately, but dramatically and progressively as the habits become internalized.
The upstream benefit compounds over time. Every document created accessibly from the start is a document that doesn’t need to be remediated later. Given that retroactive PDF remediation in Adobe Acrobat Pro can take 30 minutes to two hours per document depending on complexity, the return on a five-minute pre-export checklist is significant.
Introducing the WVNET PDF Accessibility Pre-Export Checklist
We’ve developed a comprehensive, application-specific checklist document covering the six most common tools used to create PDFs in education and government settings. Each checklist is organized by the specific steps available in that application — so staff aren’t trying to translate generic guidance into tool-specific actions.
The checklist covers:
- Microsoft Word — Heading styles, export settings, alt text, table formatting
- Microsoft PowerPoint — Reading order, slide titles, layout use, animation considerations
- Microsoft Excel — Table headers, chart alt text, print area, data labeling
- Adobe InDesign — Paragraph styles, Articles panel, export tagging, reading order
- Canva — Platform limitations, contrast requirements, remediation preparation
- Adobe Acrobat Pro — Post-export remediation for legacy and third-party PDFs
Each checklist includes a checkbox column so it can be printed and used as a physical reference, a description of the specific action required, and a note on exactly where in the application to find the relevant setting.
What to do with your existing PDF library
A checklist prevents new accessibility debt. But what about the backlog of PDFs already published on your website?
The practical answer for most organizations is triage, not wholesale remediation. Start by identifying which PDFs on your site actually get traffic — your analytics will tell you. A newsletter from 2014 that receives three visits a year is a lower priority than a current student handbook or an annual report that is actively referenced. Focus remediation effort on high-traffic, high-importance documents first.
For those documents, Adobe Acrobat Pro is the primary remediation tool. The most common quick wins — setting the document title, setting the language, and adding alt text to images — can be completed in under 30 minutes for a typical document and will resolve the majority of scanner errors. More complex structural issues, such as untagged content in documents originally created in Microsoft Publisher or Canva, require more time but follow a consistent process.
If your organization has a large existing library and limited staff bandwidth, a phased approach works well: fix the quick wins in batch for all documents, then work through structural remediation document-by-document on the highest-priority files over time.
Getting your team started
The most effective implementation follows a simple sequence:
- Distribute the checklist and walk through one example together. Showing the before-and-after in an actual PDF accessibility scanner makes the stakes concrete in a way that a policy document cannot.
- Identify your highest-volume PDF creators. Find the two or three people in your organization who create the most PDFs for public distribution, and make sure they have the checklist and understand the export workflow for their specific tool.
- Build a scan into your publication process. Tools like Pope Tech make it fast to run a PDF through an accessibility scanner before uploading, catching any issues that slipped past the checklist.
Accessibility is not a one-time project. It’s a practice. But practices build on habits, and habits build on clear, simple guidance applied at the right moment. A checklist is a small thing that solves a surprisingly large problem — one document at a time.
Source Information
- *Federal Register: federalregister.gov/documents/2026/04/20/2026-07763 — the official rule text
- *ADA.gov (DOJ’s own summary): ada.gov/resources/web-rule-first-steps/ — the DOJ’s own guidance page now reflects the extended deadlines ADA.gov
WVNET supports web accessibility compliance for K-12, higher education, and state government clients across West Virginia. Our Development Team can assist with accessibility audits, staff training, PDF remediation workflows, and Pope Tech implementation. Contact us to learn more about how we can help your organization meet its compliance obligations.