If you work for a public sector organisation or a charity with public funding, there’s a chance that PDF documents you publish online are subject to accessibility regulations or internal accessibility requirements and commitments. They’re not always straightforward to understand and can be tricky to implement. Luckily, I’ve been working with accessible documents for a long time and have all the info you need!
What “accessible PDF” actually means
An accessible PDF is a document designed for everyone to read and interact with, including people with vision, hearing, mobility, or cognitive impairments who use assistive technology such as screen readers.
Making a PDF accessible requires the document to be built with a proper underlying structure using tagged headings so a screen reader knows the hierarchy, a defined reading order so content is read in the right sequence (particularly important for multi-column layouts), alt text on every meaningful image, descrptions of complex diagrams or charts and graphs, active hyperlinks, metadata, and bookmarks for navigation in longer documents. Some of this your designer can do themselves, and some of them require additional info from clients.
Who the regulations apply to
The Public Sector Bodies Accessibility Regulations 2018 require all public sector organisations, such as central government, local government, NHS bodies, and universities, to meet the WCAG 2.2 AA standard for digital content, including documents published on their websites. Charities are not automatically exempt. If your organisation is primarily publicly funded, provides essential public services, or works specifically with disabled people, the regulations may also apply. If you’re not sure, it’s worth checking. The Equality Act 2010 applies to all service providers and requires reasonable adjustments for disabled people.
This means that any report, resource, or publication you put on your website likely needs to meet these standards or something close. And even without the legal compulsion, ensuring as many people as possible can access your publications is a good thing.
A note on GOV.UK specifically
If you’re publishing on GOV.UK or a government-managed platform, there’s an additional layer worth knowing about. Government Digital Service guidance states that HTML is the preferred format for publishing documents, and that PDFs published on GOV.UK should either be replaced with HTML versions or accompanied by one. An HTML version of a document is usually outside the scope of a graphic designer’s work.
—————
What your designer needs from you
Your designer should take care of the set up and structure of the accessible PDF but there are some bit of info only you, the client, can supply:
Chart and data summaries. For every chart or data visualisation in the document, screen reader users need a text description of what it shows, and a summary of the key finding. For example, “Donations increased by 34% year on year, with the strongest growth in Q4” is what’s needed. “Bar chart showing quarterly donations” isn’t.
Diagram and infographic descriptions. Complex visuals, theory-of-change diagrams, process maps, and frameworks also need accessibility descriptions. The more clearly you can articulate what the diagram is saying, the better. You may have to compromise some of the complexity of these elements to ensure you are providing the most important information to those using screen readers.
Photo alt text. Images that carry meaning need a short description. Decorative images don’t. Your designer will handle the distinction, but for images where context matters, a note on what the image is and why it’s there helps. A note on working with InDesign, as of 2026, it auto-generates alt-text for images; by default, it includes an “AI-generated” tag. This can be disabled in preferences, but if it’s not and no one notices, anyone using a screen reader to read your PDFs will hear the ‘AI-generated’ message.
Hyperlinks. A list of any URLs that should be active links in the document, with the destination clearly noted. Links formatted as plain text are less accessible than proper hyperlinks.
The easiest way to provide all of this is to include it in your asset bundle at the beginning of the project. I build this into my process when requesting assets before we start the design.
Baking it into the process
Accessibility works best when it’s part of the initial brief. A few things to raise before work begins:
- Tell your designer upfront that the document needs to be accessible and will be published digitally. This affects decisions made early in the layout process, structure, reading order, and how images are handled, which are much harder to unpick later.
- Ask what the deliverable includes. A properly accessible PDF requires more work than a standard export. If it hasn’t been discussed, it probably hasn’t been priced. A designer who knows what they’re doing will have a clear answer about what accessible PDF production involves and what it costs.
- Get your content signed off before the design begins. Every amendment made to a laid-out document is an opportunity for errors to creep in. Accessible elements such as tags, articles and reader order will all need to be checked again if substantial changes are made.
- Ask about the use of AI in auto-generating tags and alt-text, and make sure you are comfortable with that and how it’s being expressed in screen readers, etc.
Where I can help
I produce accessible PDFs to WCAG 2.2 AA standard as part of my document and report work. This covers tagged document structure, reading order, image alt text (from descriptions you supply), active hyperlinks, document metadata, and bookmarks if needed. I run accessibility checks in Acrobat Pro as part of the process and resolve technical failures where possible before delivery
If you’re working on a report or publication that needs to be publicly accessible and want to talk through what’s involved, get in touch.
