How to Check If Your PDFs Are Accessible: A Practical Guide for Schools and Colleges
Your website might pass an accessibility scan with flying colors. But if it links to a single PDF that a screen reader cannot parse, you have an accessibility problem — and potentially a legal one.
PDFs are one of the most commonly overlooked areas of web accessibility in education. Schools and universities post thousands of them: handbooks, financial aid documents, syllabi, course schedules, enrollment forms, athletic rosters, board meeting minutes. Most were never tested for accessibility. Many were created by scanning a paper document, which makes them completely unreadable by assistive technology.
This guide explains what makes a PDF accessible, how to test yours, and what to do when you find problems.
Why PDF Accessibility Matters for Educational Institutions
Under ADA Title II, public colleges and universities are required to make their digital content accessible, including documents linked from their websites. The compliance deadline for most public institutions is April 26, 2027. Title II does not make an exception for PDFs.
For private K-12 schools and private colleges, ADA Title III applies. Courts have consistently held that inaccessible documents linked from a website are subject to the same legal standard as the website itself. Fixing your website but leaving your PDFs untouched is not a complete compliance strategy.
Beyond the legal exposure, consider what is actually in those documents. A student who uses a screen reader and cannot access your financial aid FAQ, your housing application, or your academic calendar is not just experiencing an inconvenience. They are being denied access to information that directly affects their ability to participate in your institution.
What Makes a PDF Accessible — or Not
An accessible PDF is one that has been structured so that assistive technology can read it correctly. The key elements are:
Document tags. Tags tell a screen reader what each element is — a heading, a paragraph, a table, an image, a list item. An untagged PDF has no structure a screen reader can navigate. It either reads everything as a single undifferentiated block of text or reads nothing at all.
Reading order. The order in which a screen reader encounters content must match the logical reading order of the document. Multi-column layouts, sidebars, and callout boxes frequently cause reading order problems that automated tools flag but cannot always fix correctly.
Alternative text for images. Any image that conveys information — a chart, a photo with a caption, a diagram — needs descriptive alt text. Decorative images should be marked as decorative so screen readers skip them.
Accessible form fields. PDF forms must have properly labeled fields so a screen reader user knows what to type into each one. Unlabeled form fields are one of the most common PDF accessibility failures in education.
Document language. The primary language of the document must be declared in the document properties so screen readers can use the correct pronunciation and reading rules.
Document title. The document title (not the filename) should be set in document properties and should appear in the title bar of the PDF viewer.
Color contrast. Text in PDFs must meet the same WCAG color contrast requirements as web content: 4.5:1 for normal text, 3:1 for large text.
Scanned PDFs fail almost all of these requirements automatically. A scan is an image of a page. It has no tags, no reading order, no text that assistive technology can access. To a screen reader, it is as blank as a photograph.
The Fastest Way to Know If a PDF Is Accessible
Before running any tools, do this first: open the PDF and try to select text with your cursor. If you cannot select the text, the PDF is a scanned image and is not accessible to screen readers. Full stop. It will need to be either recreated from a source document or run through OCR processing followed by manual tagging — a more involved remediation process.
If text is selectable, the document was created digitally and may be accessible, but it still needs to be tested.
Free Tools for Testing PDF Accessibility
Adobe Acrobat Pro: Built-In Accessibility Checker
If your institution has Adobe Acrobat Pro, it includes an accessibility checker that tests against WCAG and PDF/UA standards. To run it, go to All Tools, then Prepare for Accessibility, then Check for Accessibility. Acrobat will generate a report flagging failures by category: tags, reading order, alt text, form fields, document properties, and more. It also offers automated fixes for some issues, though manual review is still required after running automated fixes.
Acrobat Pro is the most widely used tool for both checking and remediating PDFs. If your institution produces a significant volume of documents, it is worth having access to it.
PAC — PDF Accessibility Checker
PAC is a free Windows desktop application and one of the most comprehensive PDF accessibility checkers available. It tests against both WCAG 2.1 and PDF/UA (the international standard for accessible PDFs) and includes a screen reader preview that shows you what a screen reader would actually encounter when reading the document. It is particularly useful for understanding reading order problems. PAC is available at pac.pdf-accessibility.org.
PAVE
PAVE is a free web-based checker developed by the ZHAW School of Engineering. You upload a PDF and receive a detailed report of accessibility issues. It is a good option for institutions that do not have Acrobat Pro and are on Mac or do not want to install desktop software.
CommonLook PDF Validator
CommonLook offers a more comprehensive paid validator that is widely used in higher education and government. It tests against WCAG, PDF/UA, and Section 508 and provides detailed reporting useful for compliance documentation. For institutions with large document libraries and formal compliance programs, it is worth evaluating.
What Automated Tools Will and Will Not Catch
This is the most important thing to understand about PDF accessibility testing: automated checkers identify technical failures but cannot assess whether the document actually makes sense to a person using a screen reader.
A tool can verify that a chart has alt text. It cannot tell you whether that alt text actually describes the data in the chart. A tool can confirm that reading order tags exist. It cannot tell you whether the reading order produces a coherent experience when a three-column layout is read linearly. A tool can flag that form fields exist. It cannot tell you whether the label accurately describes what the user is supposed to enter.
Manual review — ideally with a screen reader — is the only way to know whether a document is genuinely usable, not just technically tagged.
A Practical Approach for Schools and Colleges
If you are looking at a website with hundreds or thousands of linked PDFs and do not know where to start, here is a practical sequence:
Inventory first. Before testing anything, know what you have. A site crawler like Screaming Frog can export a list of all URLs on your site, which you can filter to find all links ending in .pdf. This gives you a complete picture of the scope of the problem.
Prioritize by impact. Not all PDFs are equal. Start with the documents students and families use most and that are most critical to institutional access: financial aid materials, enrollment forms, academic calendars, student handbooks, housing applications. These are also the documents most likely to appear in an accessibility complaint.
Do the quick check first. Try to select text in each document. Any PDF where text is not selectable is a scanned image and goes directly onto a remediation list. Set those aside and address digitally-created PDFs first, since they are faster to fix.
Run automated testing on your priority documents. Use Acrobat Pro, PAC, or PAVE to generate reports on your highest-priority PDFs. Document the findings.
Remediate or replace. For many documents, the fastest path to an accessible PDF is to go back to the source file — the Word document or InDesign file — make it accessible there, and export a new PDF. Remediating a poorly-tagged PDF directly is often more time-consuming than starting from the source.
Consider HTML alternatives for high-traffic documents. For documents that are updated frequently or accessed by a large number of users, an HTML page is often more accessible and easier to maintain than a PDF. Student handbooks, FAQs, and policy documents are good candidates for this approach.
Preventing New Problems Going Forward
Remediating existing PDFs addresses the backlog. Preventing new inaccessible documents requires a process change.
The most effective prevention is training the people who create and post documents. Someone who knows how to create an accessible Word document before converting it to PDF will produce accessible PDFs consistently. Someone who has never been shown how to add a document title, set heading styles, or add alt text to an image will produce inaccessible ones just as consistently.
Consider building a simple accessibility checklist into your document publishing workflow. This can be as simple as a short set of questions that anyone posting a document to the website completes before it goes live. It does not need to be complicated. For most documents, checking five or six things covers the majority of common failures.
Need Help Assessing Your Document Library?
PDF accessibility is one of the areas we address as part of our accessibility audit work with schools, colleges, and universities. If your institution has a large document library and is not sure where to start, we can help you inventory what you have, identify your highest-priority remediation items, and develop a plan that fits your timeline and compliance deadline.
Schedule a discovery call to talk through your situation, or request a free homepage scan as a first step.
This post is provided for informational purposes only and does not constitute legal advice. Institutions with specific compliance questions related to ADA Title II or Title III should consult qualified legal counsel.