PDF Accessibility Checker Guide for Public Entities

This guide is general information, not legal advice. Consult your entity's counsel about your obligations.

Want a quick first look at a file? Our free PDF accessibility checker runs the basic machine checks in your browser, without uploading the document.

On most school district, city and county websites, a large share of what residents open is a PDF: board agendas and minutes, the adopted budget, lunch menus, enrollment packets, permit applications, bid notices, meeting calendars. Many of those files cannot be read by a screen reader, cannot be navigated with a keyboard, or are simply photos of paper.

This guide explains what the U.S. Department of Justice ADA Title II rule says about PDFs, how to use a PDF accessibility checker for free, what to check by hand, and how to work through a backlog of thousands of files without stopping everything else.

What the DOJ Title II rule says about PDFs

The DOJ published its web and mobile accessibility rule for state and local governments on April 24, 2024 (89 FR 31320). It added Subpart H to 28 CFR Part 35 and adopted WCAG 2.1 Level AA as the technical standard. An interim final rule published April 20, 2026 (91 FR 20902) moved the compliance dates to:

April 26, 2027 for public entities with a total population of 50,000 or more, other than special district governments.
April 26, 2028 for public entities with a total population under 50,000 and for all special district governments.

For background on the extension, see our post on the Title II deadline extension.

PDFs are "conventional electronic documents"

The rule does not treat PDFs as something separate from your website. Section 35.104 defines conventional electronic documents as "web content or content in mobile apps that is in the following electronic file formats: portable document formats ('PDF'), word processor file formats, presentation file formats, and spreadsheet file formats." The same section lists conventional electronic documents as an example of web content. In practice, that means a PDF linked from your site is held to WCAG 2.1 AA just like the page that links to it.

The exception for preexisting documents, and its limits

Section 35.201(b) exempts "conventional electronic documents that are available as part of a public entity's web content or mobile apps before the date the public entity is required to comply with this subpart, unless such documents are currently used to apply for, gain access to, or participate in the public entity's services, programs, or activities."

Read that last clause carefully. A 2019 budget presentation sitting in an old folder may fall under the exception. A kindergarten enrollment form, a building permit application, a facility rental request or the current fee schedule does not, even if it was posted years ago, because people use it today to apply for or access a service.

Two other exceptions often come up with documents:

Archived web content (35.201(a)). Under 35.104, this is content created before your compliance date (or reproducing older paper or physical media), kept only for reference, research or recordkeeping, not altered or updated after archiving, and organized and stored in a dedicated area clearly identified as archived.
Individualized, secured documents (35.201(d)). Documents about a specific person, their property or their account that are password-protected or otherwise secured, such as an individual utility bill in a customer portal.

None of these exceptions removes the general Title II duty to provide effective communication. If someone asks for an accessible version of an exempt document, you still need a process to provide it.

HTML first, PDF only when you need it

The simplest accessible PDF is the one you never publish. A lunch menu, a meeting notice, office hours or a list of permit fees reads better as a normal web page. HTML reflows on phones, works with screen readers and is easier to update. Federal guidance points the same way: Section508.gov notes that federal policy asks agencies to prefer HTML and use PDFs only when necessary.

Keep PDFs for documents where the fixed layout matters, such as the official adopted budget, signed resolutions or forms that must be printed. For everything else, consider a page.

How to check a PDF for accessibility

No checker can tell you a PDF is fully accessible. Automated tools catch structural problems, such as missing tags or a missing title. A person still has to judge whether alt text makes sense and whether the reading order matches the visual layout. Use a tool first, then do the manual checks below.

Adobe Acrobat Pro: Accessibility Check

Adobe Acrobat Pro includes an Accessibility Check (formerly called Full Check) and a "Prepare for accessibility" tool set. It reports issues such as missing tags, missing document title, figures without alternate text and table structure problems, and it can fix some of them. Acrobat Pro is a paid subscription. The free Acrobat Reader does not include these tools. Adobe's help page "Create and verify PDF accessibility (Acrobat Pro)" walks through the steps.

PAC (PDF Accessibility Checker): free, Windows

PAC is a free PDF accessibility checker, first released through the PDF/UA Foundation and now maintained by axes4. The PDF Association lists it among its resources. It runs on Windows. PAC tests a file against PDF/UA (ISO 14289) using the Matterhorn Protocol and also reports on WCAG-related checks. It also shows the document's tag structure so you can see how assistive technology will interpret it. PAC reports problems but does not fix them; you fix them in the source file or in Acrobat Pro.

Manual checks every PDF should pass

Real text, not a scanned image. Try to select a sentence with your cursor or search for a word. If you cannot, the PDF is an image and is unreadable to a screen reader.
Tagged. Open the document properties and confirm it is a tagged PDF. Tags carry the structure (headings, lists, tables) that assistive technology uses.
Logical reading order. Multi-column layouts, sidebars and text boxes often read out of order. Check the tag order or the reading order panel.
Headings. Section titles should be tagged as headings (H1, H2 and so on), not just bold text, so people can jump between sections.
Alt text on meaningful images. Charts, maps and photos that convey information need a text alternative. Decorative images should be marked as artifacts.
Table headers. Budget and schedule tables need header cells identified so a screen reader can announce "Fund: General, FY2027: 4,200,000" instead of a string of numbers.
Form field labels. Every fillable field needs a name (tooltip) that says what to enter, and the tab order should follow the visual order.
Document title and language. Set a meaningful title (not "Scan_0042.pdf") and set the document language, for example English or Spanish.
Color and contrast. The WCAG contrast rules apply to text in PDFs too, and color should not be the only way information is shown.

The W3C publishes a set of PDF techniques for WCAG that explain how each of these maps to specific success criteria, for example PDF3 on reading order and PDF1 on alternate text for images.

What is PDF/UA, and how does it relate to WCAG?

PDF/UA ("Universal Accessibility") is the ISO standard for accessible PDF files, published as ISO 14289. PDF/UA-1 (ISO 14289-1) is the version most tools check today, and PDF/UA-2 (ISO 14289-2:2024) is the newer edition based on PDF 2.0. PDF/UA defines how a PDF must be built: correct tagging, a defined reading order, alternate text, metadata such as the title and language, and so on.

WCAG is different. It describes outcomes a person needs, such as "information and relationships are programmatically determinable" or "text has sufficient contrast." The DOJ rule requires WCAG 2.1 AA, not PDF/UA. In practice they work together: a PDF built to PDF/UA has the technical foundation to meet many WCAG criteria, but you still need to check things PDF/UA does not cover well, such as color contrast and whether the content itself is clear. Passing a PDF/UA check in PAC is strong evidence, not a guarantee of WCAG conformance.

Fix it at the source: Word and Google Docs

Fixing a finished PDF in Acrobat is slow. Fixing the source file is usually faster, and the fix carries over every time the document is updated. For recurring documents like agendas and minutes, build one accessible template and reuse it.

Microsoft Word

Use the built-in heading styles (Heading 1, Heading 2) instead of bold or larger text.
Use the real list and table tools, and mark the first row of a table as a header row that repeats.
Add alt text to images and charts, or mark them as decorative.
Set the document title in File, Info, Properties.
Run Review, Check Accessibility. Microsoft's Accessibility Checker flags missing alt text, missing header rows, low contrast and other issues, with instructions to fix each one.
Export with File, Save As, PDF, and make sure the option to include document structure tags for accessibility is turned on. "Print to PDF" usually strips the tags, so avoid it.

Google Docs

The same habits apply: use real headings from the styles menu, real lists, alt text on images and simple tables. Google Docs does not offer a checker as complete as Word's, so check the exported PDF in PAC or Acrobat Pro.

Agenda and meeting software

If your board agendas come out of a meeting-management platform, the PDF quality depends on that vendor. Ask whether exported agendas and packets are tagged, and test a sample in PAC. Put accessibility requirements in the contract; our procurement guide covers what to ask for.

Scanned PDFs

A scanned page is a picture. Before anything else, run optical character recognition (OCR) so the text becomes real, selectable text. Acrobat Pro and many scanner tools can do this. OCR is only the first step: it can misread words, especially in tables, stamps and handwriting, and it does not create headings, reading order or table structure. A scanned document that people need, such as an application form, usually needs to be rebuilt from a clean source file instead.

Fillable forms

Enrollment forms, permit applications and facility request forms are exactly the documents the preexisting-document exception does not cover, because people use them to apply for services. A fillable PDF form needs labeled fields, a logical tab order, clear instructions, error-tolerant fields and a way to submit that does not depend on a mouse.

Often the better answer is an HTML form on your website or in your existing online form tool, built and tested for accessibility. If the PDF must stay, keep a phone or email alternative clearly listed next to it, and fix the form fields in Acrobat Pro.

A triage plan for a backlog of thousands of PDFs

Many districts and cities have thousands of documents on their sites. You will not fix them all, and the rule does not ask you to fix everything that qualifies for an exception. Work in this order:

Inventory. List every document linked from your site with its URL, the page that links to it, its date and, if you have analytics, its traffic. A full site crawl is the fastest way to find where documents live. A tool like PillarScan scans your HTML pages for WCAG issues and shows the pages that link out to documents; it does not test the PDFs themselves, so pair it with PAC or Acrobat Pro.
Delete what nobody needs. Expired bid notices, last year's lunch menus and duplicate copies can usually go, subject to your records retention schedule. Removing a file from the website is not the same as destroying the record.
Create a clearly labeled archive. Move old agendas, minutes and reports that are kept only for reference into an archive section, and do not edit them after archiving. Check each item against the 35.104 definition of archived web content with your counsel. Add a note that explains how to request an accessible copy.
Fix what people use to get services. Forms, applications, current fee schedules, current calendars, registration packets and policies people must follow come first, regardless of when they were posted.
Convert high-traffic documents to HTML. Your top 20 or 50 documents by traffic are usually good candidates for a web page.
Fix at the source going forward. Build accessible templates for recurring documents, train the people who post them, and add a "check before posting" step. Every new document posted after your compliance date must meet WCAG 2.1 AA.
Document it. Keep a log of what you removed, archived, fixed and converted, with dates. This record shows good-faith progress if a complaint arrives.

Frequently asked questions

Is there a free PDF accessibility checker?

Yes. PAC (PDF Accessibility Checker), now maintained by axes4, is free and runs on Windows. It checks PDF/UA and WCAG-related items. Microsoft Word's Accessibility Checker is also included with Word and helps you fix the source document before export. Adobe Acrobat Pro's Accessibility Check is useful but requires a paid subscription.

Do we have to fix every old PDF on our website?

Not necessarily. Under 28 CFR 35.201(b), conventional electronic documents posted before your compliance date are exempt unless they are currently used to apply for, gain access to, or participate in your services, programs or activities. Forms, applications and current documents people rely on must be accessible. Anything posted after your compliance date must meet WCAG 2.1 AA. You still need to provide accessible versions on request.

What makes a PDF ADA compliant?

The DOJ rule requires WCAG 2.1 Level AA. For a PDF that generally means real text, tags, a logical reading order, headings, alt text, table headers, labeled form fields, a title, a set language and adequate contrast. No tool can certify a PDF as compliant; automated checks need to be paired with a manual review.

Is PDF/UA the same as WCAG?

No. PDF/UA (ISO 14289) is a technical standard for how accessible PDFs are built. WCAG 2.1 AA is the standard the DOJ rule adopts. A PDF/UA-conformant file is well on its way to meeting WCAG, but you still need to check items like contrast and clear content.

Can OCR make a scanned PDF accessible?

OCR turns the image into real text, which is necessary but not sufficient. You still need tags, headings, reading order, alt text for images and a check for OCR errors. For important documents, rebuilding from a source file is usually faster and more reliable.

PDF accessibility checker guide: accessible PDFs for public entities