Your digital strategy can't afford inaccessible PDF documents
Before getting into it, I'd like to make it clear what I mean when I talk about digital accessibility. At its core, though, it's something very simple to see and understand. Digital accessibility means designing and developing documents, websites, apps and tools so that they can be used by as many people as possible, regardless of whether they have a disability or not.
This “can be used” means that anyone can perceive, understand, navigate and interact with these websites, apps, documents and tools, using different devices, contexts and assistive technologies such as screen readers, a keyboard, magnifiers, voice recognition, etc.
But contrary to what many people think, making something accessible is not just about complying with regulations or, for example, adding Alt text to images; it means that anyone can access the information, carry out the same tasks and use the same services.
But you may be wondering, why is this important? Because it affects more people than you might think. A significant part of the population lives with some form of permanent disability, and we also have to take temporary situations into account (such as an injury, a noisy environment, a poor internet connection or low-light conditions), where accessible design makes a difference. If the content is accessible, as well as reaching more people, the user experience improves: it becomes more usable and more efficient for everyone.
From an organisation's point of view, accessibility is, in addition to being an ethical and legal issue, a strategic decision, as it can help strengthen (or damage) reputation, search engine rankings, etc.
Documents are also part of the digital experience
At this point in the post, it is time to talk about an uncomfortable aspect that is often (more often than you might imagine) overlooked. Everything I've told you also applies to the documents we have on our websites. What's more, just as with web accessibility, for documents it is not enough for an automated validator to give our PDF a green check.
If any of the key processes or the information you want to convey depends on one of those documents and they are not accessible, this creates a blocking barrier for the user.
The false comfort of green checks
I know this is something I've already talked about, but I'm very likely to mention it again. We live in a world full of dashboards, KPIs and compliance reports, and accessibility is not exempt from all of this (which is a good thing, because anything that can be measured can be improved), but sometimes it's very easy to give in to the temptation to consider a document accessible simply because the automated validator says it is (the classic green check we're talking about), especially when we're facing an endless pile of documents, with lots of content and very little time.
I don't want to suggest that automated tools aren't useful. From an accessibility perspective, they help us detect problems in the code or, for example, missing structures—issues that are easy to overlook but that these tools can flag during an initial review of the document or website. And that's what they are useful for: a preliminary review.
The problem comes when, for whatever reason—time, knowledge, motivation, workload—we confuse that first filter with the final destination, something that any accessibility guide will identify as a mistake because no automated validator evaluates aspects such as comprehension, context or complexity, which is why documents need to be reviewed manually.
If we apply this to a PDF document, the limitations of automated tools increase. They may give us the famous green check, telling us that the PDF document contains tags, but they do not know whether that structure makes sense to someone listening to the document with a screen reader.
That is why an accessibility strategy that stops at the green check is an incomplete strategy, because we run a very high risk of leaving people out of the process.
What actually makes a PDF accessible?
I don't want to turn this article into an overly technical or exhaustive guide, but there are some elements we need to consider at a basic level that make the difference between a PDF that can be accessible and one that isn't.
- Text instead of scanned images. A document scanned as an image is completely unreadable to most assistive technologies (such as a screen reader), and requires OCR to be processed correctly and the document to be tagged (for example, if you ask NotebookLM to create a presentation for you, both the PDF and the PPT are just images). An accessible PDF contains text that can be selected and searched.
- Clear semantic structure. Tagged headings, lists, paragraphs or sections allow users to navigate the document in a similar way to a web page—for example, jumping between headings without having to go through all the content.
- Logical reading order. Layouts with columns, floating text boxes, captions and other visual elements may look good (and pretty), but they can be chaotic for screen reader users, especially if the reading order does not reflect the logic of the content.
- Images and graphics described when they convey information (the famous Alt attribute…). Graphics, diagrams and screenshots that communicate relevant data need appropriate descriptions. Images, icons, shapes, etc. that are purely decorative should not interrupt the reading experience.
- Properly structured tables. Tables with clearly defined headers, clear relationships between rows and columns, and no merged cells help users understand the table without needing to see it.
- Labelled forms. Fields with names and clear instructions, understandable error messages and a correct tab order help anyone complete the form using only a keyboard or screen reader.
- Basic metadata. Document title, declared language and other contextual information that contributes to a better user experience.
Okay, I told you it was a basic list, and that's exactly what it is: this is the minimum needed to consider a PDF document accessible. Many of these elements are content design decisions that need to be made with the end user in mind and, as you've seen, they are not things that can be fixed automatically.
Integrating document accessibility into the strategy (but not as the final step)
Based on what we've covered so far in this article, I think it's fair to say that we can assume that documents are part of the digital experience and understand which aspects we need to take into account for a PDF document to be accessible. In my view, this shifts us from asking “Who fixes the PDF?” to asking “How do we integrate document accessibility into the way we work?”.
If we want our document accessibility strategy to be robust, the key thing to keep in mind is that all these criteria I am talking about in this article must be incorporated into the workflow from the very beginning of the process, not at the end.
From a strategic point of view, I'd like to highlight some of the decisions that make a difference.
- Question when to use PDF and when not to. Everyone uses PDFs (who doesn't have an endless folder of documents to read when they have time, except that time never comes?), but content that is viewed and modified frequently and needs to adapt to different devices often works better in HTML, where accessibility and updates are easier to manage.
- Design accessible documents at the source. Tools such as Word, Google Docs or InDesign allow you to create the structure, styles or bookmarks that will later carry over to the PDF document. Proper training for the people who write and create documents will greatly reduce the need for remediation.
- Define minimum criteria before publishing. Just as we may have a style guide or quality standards, it is important to establish a minimum level of document accessibility to prevent certain errors that simply should not be acceptable when content is published.
- Combine automated validation with manual review. Using automated tools to detect objective issues and complementing them with tests (for example, using a screen reader or navigating the document with a keyboard) helps us get closer to people's actual experience.
- Identify and prioritise critical documents. Not all documents have the same impact. Contracts, policies, instructions or announcements have a different level of importance compared with other documents. We should treat the most important documents as strategic assets, with clear owners, review cycles, etc.
When we integrate the accessibility of our documents into the strategy (training, processes, format decisions, etc.), it stops being a one-off problem and becomes a standard practice, and this always benefits people.
Beyond the PDF: consistency with the promise of accessibility
To finish, whenever I talk about accessibility, I talk about consistency: making sure that the message that we want to be inclusive, or that we care about user experience, aligns with what actually happens when someone opens one of our documents.
An accessible website (and one that communicates accessibility) paired with a document that isn't accessible sends the user a contradictory message, and it doesn't matter what caused the problem: the user will perceive it as a negative experience.
When we think about digital strategy, we cannot think in terms of documents that are not accessible, because accessibility is not measured only on your website's homepage, nor is it based only on what an automated validator says. What we really need to measure is whether anyone can access and use a document without encountering avoidable barriers.
Want to know a little more about who wrote this article? 👇
Senior digital accessibility consultant with more than a decade of experience helping companies transform their products, documents and teams so they are genuinely inclusive — not just formally compliant.