PDF/UA vs WCAG: What?s the Difference?
PDF/UA is a PDF-specific technical standard. WCAG is a web-focused set of user-centred success criteria. For PDFs published online, aim to meet PDF/UA inside the file and WCAG for the web presentation to ensure accessibility and compliance.
PDF/UA vs WCAG explained in plain terms. PDF/UA and WCAG both aim to make content usable by people with disabilities. They cover different scopes and work together when PDF files appear on the web. This article shows the practical differences, how they overlap, and what to check when you must comply.
Quick comparison: PDF/UA vs WCAG
PDF/UA is a technical standard for accessible PDF files. It sets rules for structure, tagging, text alternatives and form fields inside a PDF. WCAG is a set of accessibility requirements for web content produced by W3C. WCAG focuses on perceivable, operable, understandable and robust content for people using assistive technology.
Scope and purpose
What PDF/UA covers
- Document structure and tags, such as headings, lists and tables.
- Correct reading order in the PDF tag tree.
- Text alternatives for images and figures.
- Accessible form fields and annotations.
- Metadata that helps assistive technologies understand the document.
What WCAG covers
- Web content in general, including HTML pages, multimedia, and embedded documents.
- Principles grouped as perceivable, operable, understandable and robust.
- Success criteria at levels A, AA and AAA that address issues such as keyboard access, contrast, captions and predictable navigation.
- Requirements that apply when a PDF is served on the web.
How they relate
WCAG is the goal for web accessibility. If you publish a PDF on a website, WCAG success criteria apply to that user experience. PDF/UA is a document-level standard that teaches you how to make the PDF itself accessible. In practice you often need to meet both: build the PDF to PDF/UA rules and ensure the web presentation meets WCAG.
Standards and authoritative sources
- PDF/UA is an ISO standard (ISO 14289). It focuses on PDF internals and how assistive tools interpret them.
- WCAG is produced by W3C WAI. Versions include WCAG 2.0, 2.1 and 2.2, with levels A, AA, AAA.
Testing and tools
Automatic checkers to start with
- PAC 3 from the PDF Association is a widely used PDF accessibility checker for PDF/UA checks.
- Adobe Acrobat Pro has an accessibility checker and tools to inspect tags and reading order.
- Browser accessibility tools and site scanners can flag WCAG issues for linked PDFs.
Manual tests you must do
- Open the PDF with a screen reader such as NVDA, JAWS or VoiceOver and verify reading order and alt text.
- Check keyboard focus and form-field labels without a mouse.
- Verify colour contrast for text and graphical elements against WCAG contrast criteria.
Practical steps: Make a PDF meet WCAG and PDF/UA
- Create clean source files. Use native text in Word, InDesign or LaTeX rather than scanned images. Structure headings with real styles.
- Export with tagging. Choose the export option that creates a tagged PDF. Confirm that the tag tree contains headings, paragraphs and lists.
- Set the document language and title. Both help screen readers pronounce text correctly and present the document title.
- Add alternative text for images and figures. Mark purely decorative images as artifacts when your tool allows it.
- Fix tables. Use true table markup, identify row and column headers and avoid using tables for layout.
- Label form fields. Ensure each field has a programmatic name and an accessible label.
- Check reading order. Verify the tag order matches the visual order. Do not rely on visual layering alone.
- Run automated checks with PAC 3 and Acrobat. Then follow up with manual checks and screen reader testing.
Common mistakes to avoid
- Exporting a scanned image without OCR and claiming it is accessible.
- Relying only on automatic checkers and skipping screen reader testing.
- Leaving empty or generic alt text such as “image1” or “graphic”.
- Using visual layout tricks instead of proper tags and structural elements.
- Failing to label form controls or relying solely on visual captions.
Information most guides miss
Many guides treat PDF/UA and WCAG as interchangeable or recommend only one. The practical truth is you should target both. PDF/UA gives the exact technical requirements inside the file. WCAG tells you whether the file, as presented on the web, meets user-centred accessibility goals. Treat PDF/UA as the document checklist and WCAG as the end-user compliance test.
Which should your organisation follow?
Use this quick decision guide.
- If the policy or law you must meet cites WCAG, make sure published PDFs allow people to perceive, operate and understand the content under the required WCAG level. Then fix any gaps inside the PDF by following PDF/UA rules.
- If you need a PDF-specific technical certification or a high level of document interoperability with assistive tech, use PDF/UA as the baseline.
- If both legal compliance and file-level interoperability matter, plan to meet WCAG and PDF/UA together.
Real-world scenario: government form
You publish a form PDF on a public website that must meet WCAG AA. Start in the authoring tool and add semantic headings and labelled form fields. Export a tagged PDF. Use PAC 3 to resolve PDF/UA failures, then test the final PDF with a screen reader and keyboard alone. Fix contrast or caption issues using WCAG criteria. Document your test results for procurement or legal review.
Quick checklist before publishing a PDF online
- Document title and language set
- All images have useful alt text or are marked decorative
- Headings and lists are tagged correctly
- Tables use correct header markup
- Form fields have accessible names and tab order
- Reading order verified in the tag tree
- Contrast and captions meet WCAG criteria
- Automated and manual testing completed and recorded
Final notes
PDF/UA and WCAG are complementary. One deals with the technical internals of a PDF. The other sets the user-focused rules for web content. When you publish PDFs online aim for both standards. That approach reduces barriers and lowers the risk of non-compliance.