Open the Media Library on most business sites and you will find a pile of PDFs nobody has looked at in years: the lunch menu from two seasons ago, a new patient form, an annual report, a price sheet, a scanned brochure, minutes from every board meeting since 2016. An accessibility audit usually flags them all at once, and the list looks overwhelming.
It is less overwhelming once you sort it. Some of those files should be deleted, some should become web pages, and only the rest need the work of becoming an accessible PDF. This post covers that sorting, what makes a PDF accessible, how to check one, and how to handle PDF forms. It is written for site owners and editors, not document specialists.
First question: should this be a PDF at all?
A PDF is a fixed page. It was built for printing, and it shows. On a phone, people pinch and scroll sideways. With a screen reader, an untagged PDF may read in the wrong order or not at all. With magnification, text does not reflow the way a web page does. Anything people only need to read is almost always better as a normal page.
| Content | Better as | Why |
|---|---|---|
| Restaurant menu, price list, list of services | A web page | Read on phones, changes often, easy to keep accessible in the editor. |
| Contact, intake or registration form | A web form | Fillable PDFs are hard to make and hard to use with assistive technology; web forms send the data straight to you. |
| Newsletters and announcements | A post or page | Searchable, linkable, and readable without a download. |
| Annual report, policy document, official notice | A tagged PDF, ideally with a web summary | People print, file or cite them, and the layout may need to stay fixed. |
| Outdated material nobody needs | Nothing | Delete it, or archive it off the public site if you must keep it. |
That last row matters more than it looks. Removing files is the quickest accessibility fix there is.
What makes an accessible PDF
An accessible PDF has a hidden structure underneath the visible page, called tags. Tags say “this is a heading, level 2”, “this is a paragraph”, “this is a list with four items”, “this image means X”, “this is a table, and these cells are its headers”. Screen readers read the tags, not the visual layout. A PDF without tags is, to assistive technology, a jumble of text fragments or nothing at all.
Beyond tags, a usable PDF has:
- Real text, not a picture of text. If you cannot select a word with your cursor, it is an image.
- A logical reading order, so two-column layouts, sidebars and footnotes are read in the order a person would read them.
- Headings tagged at the right levels, and bookmarks for longer documents so people can jump between sections.
- Alt text on meaningful images and charts, and decorative images marked as artifacts so they are skipped.
- Table headers marked, so a screen reader can say which column a number belongs to.
- A document title and language set in the file’s properties, so the title, not the file name, is announced, and the right voice is used.
- Descriptive link text and enough color contrast, the same as on a web page.
These map to the same WCAG criteria as web content: 1.1.1 Non-text Content for images, 1.3.1 Info and Relationships for structure, 1.4.3 for contrast, 3.1.1 Language of Page and so on. Audits treat the documents you publish on your site as web content, judged against the same criteria as the HTML around them.
Scanned PDFs are the hardest case
A scan is a photograph of paper. Many offices have years of them: signed letters, old brochures, handouts photocopied and scanned again. Running text recognition (OCR) adds a text layer, which is a start, but OCR text is often wrong in places and still has no structure. Turning a scan into an accessible PDF usually means correcting the recognized text and then tagging it, which can take longer than retyping the content as a web page.
So for scans, ask the first question again, and harder. If the content still matters, retype it as a page. If you need to keep the original for record, keep it, and publish an accessible version next to it.
PDF accessibility for websites starts at the source
Most PDFs on business sites were exported from a word processor or a design program. The structure that ends up in the PDF comes from the source file. If the original used real heading styles, real lists, alt text on images and table header rows, and if the export kept the tags, much of the work is already done. If headings were just bold text in a bigger size, the PDF will have no headings either.
That makes the source file the easiest place to fix things, especially for documents you update every year. Fix the template once, and every future export is better. The specific steps vary by program and version, so follow your program’s own accessibility guidance when exporting, and keep the source file safe so you are not editing the PDF every time.
Checking an accessible PDF
You do not need specialist software for a first pass:
- Open the PDF and try to select a sentence. If you cannot, it is an image and needs text.
- Look at the document title shown in the browser tab or the viewer’s title bar. Is it a real title or a file name like “final_v3_print”?
- Zoom in a long way. Does the text stay crisp, or is it a blurry picture?
- If you have a screen reader, such as NVDA on Windows or VoiceOver on a Mac, open the file and listen to the first page. Does it read in a sensible order? Are headings announced?
For a proper check and for fixing, Adobe Acrobat Pro is the common tool. It includes an accessibility checker that reports problems such as missing tags, missing alt text, an unset language or a missing title, and it has tools for viewing and editing the tag structure and the reading order. The free Acrobat Reader can open files but not fix them. Menu names move between versions, so use Adobe’s current help for the exact steps.
Treat the automated checker the way you would treat a website scanner. A clean result means the mechanical parts are in place. It does not tell you whether the reading order makes sense, whether the alt text is accurate, or whether headings are at the right levels. Someone has to read through the tags or listen to the document.
PDF forms
Fillable PDF forms add another layer. Each field needs a name that a screen reader can announce (often set as the field’s tooltip), the fields need a sensible tab order, required fields need to be marked in text as well as color, and checkboxes and radio buttons need grouping that makes sense out loud. A flat PDF that people have to print, fill by hand and scan back is not accessible at all.
In most cases, a web form is the better answer. It works on phones, it can be built to WCAG with proper labels and error messages, and the answers come straight to you. Our page on accessible web forms explains what that work involves. If you must keep a PDF form, for example because a regulator supplies it, offer a web form or a phone or email option beside it.
The website side of PDFs
Even an accessible PDF can be awkward to reach. A few habits on the page around it:
- Say it is a PDF in the link, and roughly how large: “2026 annual report (PDF, 3 MB)”. People on phones and slow connections want to know before they tap.
- Give the link a real name. A link that reads as the file name is not descriptive.
- Be careful with embedded PDF viewers. Some trap keyboard focus or are hard to use with a screen reader. Always offer a plain download link as well.
- Put a short summary of the document on the page, so people can decide whether they need it at all.
Our post on adding a PDF to WordPress covers the embed and download options in practical terms.
For state and local government sites, documents deserve particular attention. The DOJ’s 2024 rule under ADA Title II adopted WCAG 2.1 AA for web content, and public bodies tend to publish many documents. Our page on Title II web accessibility for public bodies covers that context; check ada.gov for the current dates, and ask your attorney about which documents are in scope.
A sensible order for a PDF backlog
- List every PDF linked from the site, with the page it is linked from.
- Delete or unlink what is outdated.
- Convert reading-only content (menus, price lists, newsletters) into pages.
- Replace PDF forms with web forms where you can.
- Fix the source templates for documents you produce regularly.
- Remediate the remaining PDFs, starting with the ones people actually open.
- Set a rule for new uploads: no untagged PDFs go on the site.
Documents are one of the content areas covered in our guide to accessible web content. If you want help with the wider site, our website accessibility services cover audits, fixes and ongoing checks.
Frequently asked questions
Does every old PDF on my site need to be made accessible?
Not necessarily. Start by removing what is outdated and converting what works better as a page. Then fix the documents people still use, especially those linked from main pages. If you have a legal obligation that covers archived documents, such as a public body under Title II, ask your attorney how it applies, because that is a legal question rather than a technical one.
Can I make a PDF accessible without Adobe Acrobat Pro?
Partly. Exporting from a well-structured source file with tags switched on gets you a long way, and some word processors do this well. Checking and fixing the tag structure afterwards usually needs Acrobat Pro or another dedicated PDF tool. For simple documents, turning the content into a web page often avoids the problem entirely.
Is a PDF that passes the Acrobat accessibility checker accessible?
It has the basics in place, but not necessarily. The checker finds missing tags, titles, language settings and alt text. It cannot judge whether the reading order makes sense, whether headings are at the right levels, or whether the alt text actually describes the image. A person needs to review the tags or listen to the file with a screen reader.
Should I put a web page and a PDF of the same content on my site?
That is often a good arrangement for reports and official documents. The web page serves most readers, and the PDF serves people who need to print or file it. Keep them in step when the content changes, and make the PDF accessible too, since some people will open it regardless.
If your site leans heavily on PDFs because its page templates are hard to edit, that is a design problem as much as a document one. An accessible redesign can give you page layouts flexible enough that menus, price lists and reports live as real pages, which leaves far fewer documents to remediate.
Next in this series: Accessible Fonts: Size, Spacing and Readable Type
