PDF Accessibility: How to Create Accessible PDFs
By EVERNET Consulting · · 6 min read
Every organization has them: the brochure from three years ago, the intake form someone scanned on the office copier, the annual report exported in a hurry the night before it went online. PDFs pile up on websites because they are easy to post. They are also, very often, the least accessible content a site has.
A PDF that looks perfectly fine on screen can be unreadable to a screen reader. Without the right structure underneath, assistive technology may read the text in the wrong order, skip the headings or miss form fields entirely. A scanned PDF with no text layer is simply a picture of a page. Here is what makes a PDF accessible, how the PDF/UA standard fits in, and a practical workflow for getting your documents right.
Why PDFs matter for accessibility
When you post a PDF on your website, it becomes part of your website, and the same expectations apply. Someone who can’t open your application form or read your policy document faces the same barrier as someone who can’t use a web page.
For state and local governments, the ADA Title II rule makes this explicit. New documents posted after the compliance date must meet WCAG 2.1 AA, and older documents are exempt only if no one currently needs them to apply for, access or take part in a service. For businesses, courts and settlements treat documents the same way they treat the rest of the site.
What an accessible PDF needs
An accessible PDF is built on tags, a hidden structure that tells assistive technology which parts of the page are headings, paragraphs, lists, tables and images. Tags are what let a screen reader user jump between sections instead of listening to the whole document from the top.
On top of that structure, a few more things need to be right. The reading order should match the visual layout, so a two-column page isn’t read straight across both columns. The document should contain real text rather than a scan; if you only have a scan, run optical character recognition and check the result. Meaningful images, charts and diagrams need alt text, and tables need header cells marked so each data cell is read with its row and column. Set a document title and language in the file properties, add bookmarks to longer documents, and if the PDF is a form, give every field a label and a logical tab order. And as with any web content, check color contrast and never convey information by color alone.
PDF/UA and WCAG: how they fit together
PDF/UA, short for Universal Accessibility, is the ISO standard for accessible PDF files. PDF/UA-1 is published as ISO 14289-1:2014, and PDF/UA-2, ISO 14289-2:2024, is built on PDF 2.0 and its tagged PDF rules. It defines the technical requirements for how an accessible PDF, and the software that reads it, must be structured.
PDF/UA and WCAG complement each other. PDF/UA focuses on correct tagging and structure; it doesn’t address visual matters like color contrast, which WCAG covers. For documents on a website, aim for both: PDFs that meet WCAG 2.1 AA and are structured to PDF/UA.
Build accessibility in at the source
Fixing a finished PDF is slow, fiddly work. It is far easier to build accessibility into the document you create it from.
In Microsoft Word, that means using the built-in heading styles instead of just making text bigger and bold, using real lists and simple tables with a header row, and adding alt text to images. Before exporting, run Word’s Accessibility Checker (Review, then Check Accessibility) and fix what it reports. Then export with File, Save As, choose PDF, and make sure “Document structure tags for accessibility” is selected under Options. Printing to PDF throws the tags away.
In Adobe InDesign, set up paragraph styles, define the reading order with articles, add alt text and export a tagged PDF. The same principle applies to any tool: structure first, export second.
Check the result
Even a well-built source document can come out with problems. Run the accessibility checker in Adobe Acrobat Pro and review the tags and reading order panels. Use the free PAC (PDF Accessibility Checker) to test against PDF/UA. Then open the file with a screen reader and listen to the headings, tables and form fields, just as a visitor would.
Does it need to be a PDF? Often the best fix is to publish the content as a web page instead. A page is easier to make accessible, easier to find in search and easier to keep up to date. Keep PDFs for documents people genuinely need to download or print.
One more point: accessibility widgets, including accessiBe, which we use on our site, work on web pages. They can’t reach inside a downloaded PDF, so documents need to be made accessible on their own.
Include documents in your audit
Most organizations don’t know how many PDFs their site links to until someone counts. An EVERNET website accessibility audit can include your most-used documents and forms alongside your page templates, so you know what to fix, replace or archive. Municipalities should also read our ADA Title II website compliance guide, which explains the exceptions for older documents.
Let’s talk about what comes next.
Bring the challenge. We’ll help you explore the right scope and a practical next step.