Does WCAG apply to PDF files?
It does, on two levels. First, the W3C wrote WCAG for "content" generally and publishes a dedicated set of PDF Techniques showing how to satisfy the criteria in PDF documents. Second - and more importantly for compliance - the legal instruments that reference WCAG apply it to documents:
- EN 301 549 dedicates Chapter 10 to non-web documents, applying the WCAG success criteria to every PDF a covered organisation publishes - which is how the European Accessibility Act reaches your documents.
- Section 508 explicitly covers electronic documents in US federal contexts.
- ADA practice: US web accessibility claims routinely include the PDFs a site serves - statements, forms, menus, reports. The Title II rule covers documents that are part of a public entity's services.
The practical consequence: if your compliance program tests HTML pages and skips the document library, the most-downloaded files on the site - invoices, contracts, guides - are usually its biggest open risk.
WCAG vs PDF/UA: what each one covers
PDF/UA (ISO 14289) is the PDF-native accessibility standard, published in two parts: PDF/UA-1 (ISO 14289-1, for PDF 1.7) and PDF/UA-2 (ISO 14289-2, for PDF 2.0). It is not a competitor to WCAG - it is the file-format layer underneath it:
| WCAG 2.1 / 2.2 | PDF/UA-1 and PDF/UA-2 | |
|---|---|---|
| What it defines | Outcome requirements for any content: perceivable, operable, understandable, robust | How a PDF must be built internally: tag structure, reading order, Unicode mapping, metadata, embedded fonts |
| Covers contrast, media, reflow | Yes - 1.4.3, 1.4.10 and the rest | No - PDF/UA leaves visual presentation to WCAG |
| Covers tag-tree correctness | Indirectly, via 1.3.1 and 1.3.2 | Yes - in exhaustive, machine-verifiable detail |
| Referenced by law | EN 301 549, EAA, ADA rule, Section 508 | Referenced as the technical method (EN 301 549 cites it as a way to satisfy Chapter 10) |
| Conformance | Per level: A / AA / AAA | Binary: a file conforms or it does not |
The working rule: target WCAG Level AA as the legal bar, and validate against PDF/UA (both UA-1 and UA-2) as the engineering bar. A file can pass PDF/UA and still fail WCAG on contrast; it can look WCAG-friendly and be unreadable to a screen reader because the tags are wrong. Testing both closes both gaps.
How WCAG criteria map to a PDF
The same criteria you test on a web page take a specific technical form inside a PDF. The high-impact mappings:
| WCAG criterion | In a PDF file, this means |
|---|---|
| 1.1.1 Non-text Content | Alternate text on every Figure tag; decorative graphics marked as Artifacts |
| 1.3.1 Info and Relationships | A complete tag tree: H1-H6, P, lists as L/LI, tables with TH/TD and headers |
| 1.3.2 Meaningful Sequence | Tag order = reading order, especially in multi-column layouts and forms |
| 1.4.3 Contrast (Minimum) | Text over backgrounds and images meets 4.5:1 - the criterion PDF/UA does not check |
| 1.4.5 Images of Text | No scanned-image pages: OCR + tagging so text is real and selectable |
| 2.4.2 Page Titled | Document Title set in metadata and displayed instead of the file name |
| 2.4.5 Multiple Ways | Bookmarks mirroring the heading structure in long documents |
| 3.1.1 Language of Page | The /Lang entry set on the document, and on passages that switch language |
| 3.3.2 Labels or Instructions | Form fields with tooltips carrying the visible label |
| 4.1.2 Name, Role, Value | Interactive form fields exposing name, role and state through tags and the form dictionary |
Matterhorn: how PDF/UA conformance is tested
The Matterhorn Protocol, published by the PDF Association, translates PDF/UA into a concrete test plan: 31 checkpoints broken into failure conditions, each marked as machine-verifiable or requiring human judgement. That split mirrors web testing: software can prove a tag tree exists, fonts map to Unicode and metadata is set; only a person can confirm the alt text is meaningful and the reading order makes sense.
This is exactly how the EqualWeb PDF checker works: 80+ automated checks across 8 categories (structure, tagging, reading order, alternate text, tables, forms, metadata, fonts) validate against both PDF/UA-1 and PDF/UA-2, and the report separates what is machine-proven from what needs expert review. Conformance is reported as binary - a document passes or it does not - because that is how PDF/UA defines it.
Making a PDF library accessible: the workflow
- Inventory and triage. Most organisations discover thousands of PDFs; not all matter equally. Prioritize documents that are part of active services - forms, statements, current guides.
- Automated check. Run the collection through the checker (single files up to 400 pages / 100MB, batches up to 1,000 documents) to map failures by category.
- Remediate. AI auto-remediation rebuilds tagging, reading order and metadata at scale; certified experts handle complex tables, forms and judgement calls.
- Fix at the source. Update the Word/InDesign templates that generate the documents, so next month's output is born accessible instead of remediated again.
- Verify and keep evidence. Re-check remediated files and retain the reports - the same evidence logic as a VPAT on the web side.
Frequently asked questions
Does WCAG apply to PDF files?
Yes. The W3C publishes PDF-specific techniques for meeting WCAG, and the laws that reference WCAG - EN 301 549 (Chapter 10), Section 508, the ADA - apply it to published documents, not only web pages.
What is the difference between WCAG and PDF/UA?
WCAG defines accessible outcomes for any content; PDF/UA (ISO 14289) defines how a PDF file must be built internally - tags, reading order, Unicode, metadata. PDF/UA does not cover visual requirements like contrast, so documents are tested against both.
What is a tagged PDF?
A PDF with an internal structure tree (tags) that tells assistive technology what each element is - headings, paragraphs, lists, tables, figures - and in what order to read them. Without tags a screen reader gets an unstructured stream or nothing.
Can a scanned PDF be accessible?
Not as-is: a scan is a picture of text and fails WCAG 1.4.5 and 1.1.1. It becomes accessible through OCR (real text) plus tagging - a standard step in remediation.
Is PDF/UA-1 enough, or do I need PDF/UA-2?
PDF/UA-1 (ISO 14289-1) covers PDF 1.7 files; PDF/UA-2 (ISO 14289-2) is the current part for PDF 2.0. Validate against both - the EqualWeb checker tests both, with UA-2 as the engine default.
How do I check if a PDF is accessible?
Run it through an automated PDF accessibility checker for the machine-verifiable failures (tags, metadata, fonts, alt-text presence), then have the judgement items - reading order, alt-text quality, table logic - reviewed by a person. The EqualWeb checker runs 80+ checks across 8 categories, free.
- W3C WAI, PDF Techniques for WCAG - w3.org/WAI
- ISO, ISO 14289 (PDF/UA) parts 1 and 2 - iso.org
- PDF Association, Matterhorn Protocol - pdfa.org
- ETSI, EN 301 549, Chapter 10: Non-web documents - etsi.org
Last updated . Reviewed by the EqualWeb accessibility team.
Check any PDF against WCAG and PDF/UA - free
80+ automated checks across 8 categories, validated against PDF/UA-1 and PDF/UA-2, with AI remediation and certified experts behind it. No credit card required.