Accessibility Compliance
How to Make PDFs Accessible (PDF/UA)
A PDF that looks perfectly normal on screen can be entirely unusable to someone using a screen reader - no reading order, no way to know what a scanned image says, form fields with no labels. PDF/UA (ISO 14289) is the international standard that defines what makes a PDF genuinely accessible, and it's increasingly what regulators and procurement teams check documents against. Here's what it requires in practice.
Why a visually fine PDF can still fail completely
Most inaccessible PDFs share one root cause: they were created by exporting from a design tool or scanning a paper document, with no attention to the document's underlying structure. A screen reader doesn't see the visual layout - it reads the document's tag tree, and if that tree doesn't exist or is wrong, the reading experience ranges from confusing to completely blocked.
What PDF/UA actually requires
- A complete, correctly ordered tag tree reflecting the logical reading order - headings, paragraphs, lists and tables all properly tagged, not just visually styled.
- Alt text for every meaningful image, and tags marking purely decorative images as artifacts so screen readers skip them.
- Table headers correctly associated with data cells, especially for complex or multi-level tables.
- Form fields with programmatic labels, not just visually adjacent text.
- A specified document language, with language changes marked where content switches mid-document.
- Correct bookmarks and a meaningful document title in the metadata, not a filename.
Scanned documents are usually the worst offenders
A scanned page is just an image to a screen reader, with zero text content, unless OCR has been run and the result properly tagged. Bulk-scanned document archives - old statements, historical forms - are almost always a bigger remediation project than born-digital PDFs.
Remediation approaches that actually scale
- Fix the template or export settings at the source, for PDFs generated from a CMS or document-generation system, so every future document is accessible by default.
- Batch remediation tooling plus manual QA for existing document archives, rather than fully manual one-by-one fixes.
- A PAC (PDF Accessibility Checker) or similar validation pass plus actual screen-reader testing, since automated PDF/UA checkers miss issues the same way web accessibility scanners do.
Need help with this in practice?
A5 Cyber Nexus audits, remediates and certifies against these frameworks.
Frequently asked questions
Does making a PDF accessible mean just adding alt text?
No - alt text is one piece. Reading order, table structure, form labels, language tagging and bookmarks all matter, and automated tools that only check for alt text miss most real issues.
Should we just convert our PDFs to accessible HTML instead?
Sometimes that's the better answer, especially for frequently-updated or complex documents - but for legally or financially significant documents (contracts, statements) that need to retain their exact formatting, a properly tagged PDF/UA document is usually the right approach.
Make it accessible.
Make it attack-ready.
Prove both before launch.
Bring us your app, audit deadline, or security concern. We'll map the fastest path to WCAG conformance, VAPT coverage, and regulator-ready evidence.
