From PDF Check to Accessible Documents: A Practical Workflow
For most public entities, the biggest accessibility risk is no longer the website template. It is the public-facing PDFs and Office documents people download every day.
Forms, policies, meeting packets, reports, and public records often sit untouched for years. Even when a website looks modern and accessible, those files can still fail basic checks for screen readers, keyboard access, reading order, headings, tables, and form labels.
That is the good news and the challenge. You do not need to rebuild your entire website to make visible progress before the ADA Title II digital accessibility deadlines. But you do need a practical way to find your riskiest documents, test them, fix what matters first, and show evidence that progress is happening.
This workflow gives you a simple way to do that.
At a Glance
Who this is for: IT, digital, ADA / 504, records, and department leaders responsible for public-facing documents.
Standard you are targeting: WCAG 2.1 Level AA, with PDF/UA where appropriate.
Why this workflow works: It focuses on the documents people actually use, not every file you have ever published.
Deadlines to plan around: April 24, 2026 for public entities serving 50,000 or more people, and April 26, 2027 for smaller entities and special districts.
Fast first step: Run a PDF accessibility check on a small set of your highest-visibility public documents and use the results to decide what to fix first.
The Practical Workflow
1. Find Your Highest-Risk Documents
Start with impact, not perfection. You do not need to inventory every file on day one.
Begin with the documents that matter most to the public and create the most exposure for your agency.
High-traffic forms and applications
Meeting agendas, minutes, and packets
Policies and notices tied to rights, benefits, or deadlines
Public records that are likely to be requested or reviewed
If you already know which forms or packets get the most use, start there. If not, look at download counts, department feedback, and public records history.
Create a simple working list with fields such as:
Bullets
Document name
Department
Document type
Public URL or file location
Audience
Notes on risk or complexity
This becomes your first sprint list.
2. Run A Small Accessibility Check
Once you have a shortlist, test a small sample of documents. You do not need a giant audit to learn something useful.
Use a PDF accessibility checker to review a set of high-priority files and look for issues such as:
Missing tags or headings
Incorrect reading order
Unlabeled form fields
Missing alt text on images or charts
Inaccessible tables or lists
The goal here is not to generate a technical report no one reads. The goal is to answer practical questions:
Which documents fail immediately?
Which issues show up again and again?
Which files are simple to fix, and which are complex?
A small sample is often enough to reveal where your biggest document accessibility gaps are.
3. Fix What Matters First
Do not try to fix every document at once. Triage the work.
A simple way to think about it:
High-risk, simpler documents should be fixed first
High-risk, complex documents may need expert remediation or redesign
Lower-risk legacy files may be handled later, archived, or replaced with more accessible formats
Many teams move faster when they use a tiered approach:
Automated or routine fixes for straightforward PDFs
Expert review for complex forms, tables, and critical public documents
The key is consistency. Publish visible wins every week if you can. A small number of corrected high-impact documents is more valuable than a vague promise to “work on accessibility later.”
4. Keep Simple Proof and Basic Rules
Progress is much easier to defend when you keep a simple record of what was tested and fixed.
For each remediated document, keep at least:
A short accessibility check summary or report
A note on what was fixed and when
A clear status such as Needs Fix, In Progress, or Pass
This does not need to be complicated. It can live in a spreadsheet, SharePoint list, or another tracking system your team already uses.
Then put a few basic rules in place for new documents:
Use real headings, not manual bold text
Label forms and tables clearly
Add alt text to meaningful images
Run an accessibility check before publishing
Keep proof of testing in a consistent place
This is where your Document Accessibility Governance Kit becomes useful. The workflow in this blog helps you get started. The Governance Kit helps you keep going.
What "Good" Looks Like
You know this workflow is working when:
Your highest-risk public documents have been tested and prioritized
The first wave of high-impact forms and packets has been fixed
Your team can show simple proof of what was checked and corrected
New documents are being published with basic accessibility checks built in
Monthly reviews show a shrinking backlog instead of a growing one
You do not need perfection in the first month. You need traction, evidence, and a clear next step.
Glossary in Plain English
WCAG 2.1 Level AA: The accessibility standard most public entities are targeting under ADA Title II.
PDF/UA: The technical standard for accessible PDFs.
PDF Accessibility Checker: A tool that identifies common accessibility issues in PDFs and helps show what passes or fails.
Public Records/PRR/FOIA: Requests for public documents that often increase the importance of having accessible files and clear evidence of remediation.
Get the Starter Tools
If you want to apply this workflow in your own environment, start with:
The Document Accessibility Readiness Checklist
The Document Accessibility Governance Kit
The 30-Day Document Accessibility Action Plan
If you want to see how your own documents perform, start with an up to 100-page PDF accessibility check or book a 20-minute document accessibility review.
