PDF vs. WCAG: Navigate the standards for digital accessibility

PDF/UA and WCAG both appear in accessibility compliance conversations, and most organizations assume they're covering the same ground. They're not. PDF/UA is a structural specification. It governs how a PDF file is built. WCAG is a content guideline. It governs what that file communicates to users with disabilities. Confuse the two and you end up with documents that pass a content review but fail a structural audit or a compliance program that duplicates effort because nobody drew a clear line between the two.

Drawing that line is what this guide does. Here's what you'll come away with:

• A clear definition of what each standard requires
• A framework for determining which standard (or which combination) governs your organization's obligations
• A map of the major legal mandates (e.g., ADA Title II, Section 508, and the EAA) and where they land on this
• A compliance workflow that validates both standards without running two separate audits

Siteimprove’s analysis of enterprise document libraries consistently identifies the same structural failure pattern: organizations invest heavily in content accessibility review while shipping PDFs with structural issues screen readers can’t navigate. The content passed the WCAG review. The PDF/UA layer didn’t.

Let’s start with PDF/UA. This is the one most compliance teams know the least about.

Understand PDF/UA standards

PDF/UA (ISO 14289) is the only PDF specification built specifically for the PDF file format. It sets binary conformance requirements for document structure, tagging, reading order, and metadata. A file either meets them, or it doesn't.

PDF/UA conformance is where most compliance programs go wrong. Teams spend weeks reviewing content for clarity and plain language, then ship a PDF that a screen reader processes as a stream of untagged noise. The content was fine. The file structure wasn’t. PDF/UA is what governs the structure. An accessible PDF starts there, not at the content layer.

Unlike guideline frameworks that offer flexibility and interpretation, PDF/UA ISO 14289 standard is a specification. That distinction matters in practice because it means that:

• Every real content element (e.g., headings, paragraphs, tables, and images) must be tagged with the correct structural role.
• Reading order must be defined in the tag tree, not left to the viewer to guess.
• Document metadata must identify the primary language.
• Decorative elements must be marked as artifacts so assistive technologies skip them.

A PDF that skips any of these requirements is structurally invisible to screen readers, regardless of how well-written or designed it is. Clean prose and good visual hierarchy don't automatically transfer to assistive technology. The tag structure is what does that work, and PDF/UA is the standard that defines what correct tagging looks like.

Explore WCAG standards

WCAG defines what accessible digital content must deliver for users with disabilities, but the standard was built for web content. WCAG doesn’t include native file-format criteria for PDFs. W3C has published specific PDF techniques for applying WCAG success criteria to PDF documents. But these are implementation guidance, not a structural specification for the format itself. The structural specification for PDF files — PDF/UA, ISO 14289 — fills that gap.

Siteimprove’s analysis of enterprise PDF libraries consistently finds the same failure pattern: thorough WCAG content reviews shipping documents screen readers still can’t navigate. The content met the WCAG guidelines. The file structure didn’t, because WCAG has no native mechanism to govern it.

The four POUR principles break down like this:

These four principles define what users with disabilities need — but WCAG’s core specification has no native mechanism to verify that a PDF file achieves them structurally. That’s the gap PDF/UA closes. W3C maps the POUR principles to PDF files through a separate techniques supplement, not the core specification itself. That gap matters when you’re building a compliance program. Understanding WCAG is a necessary starting point, but it won't tell you whether your PDF file is structurally sound.

On the regulatory side, ADA Title II and the EAA reference WCAG 2.1 AA as the compliance floor. Section 508 is an important exception, as the 2017 Refresh incorporated WCAG 2.0 Level AA. Tracking WCAG 2.1 and 2.2 updates is smart for future proofing. But for PDFs, meeting WCAG 2.1 AA in practice requires structural conformance that only PDF/UA provides.

Key differences between PDF/UA and WCAG

PDF/UA and WCAG each govern a distinct layer of accessibility. Most organizations need both working together to cover the full compliance picture.

The clearest distinction: PDF/UA audits the file structure; WCAG audits the experience it delivers. Is WCAG sufficient for PDF accessibility compliance on its own? No. A document can satisfy every WCAG success criterion while still failing a structural PDF/UA audit — both standards address different layers, and neither makes the other redundant. It constantly happens in legal and government publishing.

The structural layer must be right first. Once assistive technology can parse the file, WCAG criteria validate what users encounter inside it. Siteimprove’s audit findings consistently point to the same cause: organizations that get the sequence wrong — content before structure — fail audits they thought they were prepared for.

Legal and compliance implications

Most major accessibility regulations now reference WCAG 2.1 AA. However, Section 508 is an important exception. The 2017 Section 508 Refresh incorporated WCAG 2.0 Level AA, not 2.1. ADA Title II (2024 DOJ rule) and the EAA (via EN 301 549) reference WCAG 2.1 AA. But for PDFs, meeting that standard structurally requires PDF/UA. Regulators and auditors increasingly expect both, and the organizations caught off guard are usually the ones who only checked one.

Here's how the legal landscape breaks down by scenario.

Government agencies under ADA Title II

ADA title II document accessibility requirements apply to state and local government entities. The mandate is WCAG 2.1 AA. But PDF/UA compliance is what makes that standard achievable in a PDF file. Any PDF published as part of a public-facing service must meet WCAG 2.1 AA, and as this article explains, meeting that standard structurally in a PDF file requires the kind of conformance PDF/UA governs.

The 2024 DOJ rule includes several specific exceptions where WCAG 2.1 AA conformance is not required, such as with:

• Frameworks for conventional electronic documents that existed before the compliance date
• Electronic documents that haven't been modified or replaced since and aren't used to apply for, gain access to, or participate in the public entity's services, programs, or activities
• Archived web content maintained solely for reference
• Content posted by third parties not under contract
• Documents behind a secure portal that are about specific individuals
• Preexisting social media posts

Note: On April 20, 2026, the DOJ issued an Interim Final Rule extending these deadlines by one year. Public entities with populations of 50,000 or more must now comply by April 26, 2027. Smaller entities and special district governments have until April 26, 2028. The substantive WCAG 2.1 AA requirements are unchanged. Compliance teams should consult legal counsel to assess which documents in their library may qualify.

Federal contractors under Section 508

Section 508 applies to federal agencies and the contractors that supply them with technology. Section 508 sets WCAG 2.0 Level AA as its legal floor, not 2.1. The 2017 Refresh incorporated WCAG 2.0 by reference. Many agencies now target WCAG 2.1 AA as a best practice, but the statutory requirement remains WCAG 2.0 AA. PDF/UA provides the structural foundation for meeting document accessibility requirements under either version. Procurement teams take note: This applies to vendor-supplied PDFs too, not just internally produced ones.

Private sector under the EAA

The EAA compliance requirements took effect in June 2025. The Directive applies to economic operators in specific covered sectors, including e-commerce, banking and financial services, electronic communications, transport booking, e-books, and consumer hardware (such as computers and smartphones). It doesn't apply to private-sector companies selling any product or service in EU member states.

Existing services that were provided before June 28, 2025, benefit from a transitional period. Service providers may continue under existing service contracts until those contracts expire, and in any case, no longer than June 28, 2030 (Article 32 of the Directive). Products placed on the market before June 28, 2025, aren't covered by the Directive unless they are substantially modified.

Microenterprises (defined as businesses with fewer than 10 employees and annual turnover or balance sheet not exceeding €2 million) are exempt from the EAA's service-related requirements. This exemption does not apply to microenterprises that manufacture or distribute covered products.

As a Directive, the EAA was transposed into national law by each EU member state (transposition deadline: June 28, 2022). Enforcement (including penalties for non-compliance) is handled by national market surveillance authorities. Specific obligations and enforcement intensity may vary by country. Consult national legal counsel for country-specific requirements.

The EAA's accessibility requirements are defined in the Directive's Annexes. EN 301 549 is the harmonized European standard that operationalizes those requirements and incorporates WCAG 2.1 AA for web and document content. But it extends beyond WCAG, with additional requirements covering hardware, software, documentation, and telecommunications services not addressed by WCAG alone. For PDFs, the same combined requirement applies.

Practical steps to achieve compliance

A compliance program covering both PDF/UA and WCAG doesn’t require two separate audits running in parallel. Siteimprove’s structure-first compliance sequence validates PDF/UA structural conformance before WCAG content review — so remediation effort lands where it matters.

The sequence looks like this:

1. Audit for PDF/UA structural conformance: Check tagging, reading order, language metadata, and artifact marking across your document library. Flag failures by document and severity.
2. Assess against WCAG 2.1 AA success criteria: Use the W3C Techniques for WCAG 2 as your reference. The current techniques document covers all WCAG 2.x versions and includes PDF-specific techniques.
3. Remediate by failure category: PDF remediation is faster when you group fixes by type rather than document. Working through a batch of the same failure across multiple files saves more time than fixing one document end-to-end at a time.
4. Establish ongoing monitoring: Siteimprove maps PDF audit findings to both PDF/UA and WCAG criteria so teams can assess compliance against whichever standard governs them without running separate tools.

The teams that get this right treat PDF/UA conformance as the gate. Nothing moves to WCAG review until the structural layer passes. It sounds rigid, but it saves significant rework. Fixing content accessibility in a structurally broken file is like building a house with a cracked foundation. The work won’t hold.

For ongoing compliance, three habits make the difference: accessible authoring templates that produce correctly tagged output by default, pre-publication review workflows that catch issues before files go live, and scheduled re-audits as document libraries grow. Section 508 PDF requirements offer a useful benchmark for structural expectations even if your organization isn't a federal contractor.

Case studies and real-world applications

PDF libraries at large institutions are where the PDF/UA vs. WCAG confusion does the most damage. Thousands of documents, distributed publishing, and no central review process. That's the environment where structural failures compound unnoticed until an audit or a complaint forces the issue.

When Siteimprove scanned the top 10 websites at the University of California, San Francisco (UCSF), it found approximately 700 PDFs with accessibility barriers. The most common problem was a missing document title, which is the first piece of information a screen reader communicates when opening a file. That's a PDF/UA structural failure. A standard WCAG content review wouldn't have caught it.

UCSF's response focused on direct outreach to website owners about flagged PDFs, resulting in edits to 273 documents (a 36 percent improvement) within a few months. The bigger shift was upstream. They partnered with Learning & Organization Development to build a customized training program that gives content creators a self-serve path to understanding what PDF universal accessibility requires at the file level.

Remediating 273 documents closed the immediate gap. Building creator education stopped the same failures from arriving in the next batch. That's the governance model that holds and the one that scales as document libraries grow and publishing teams turn over.

Start with structure, finish with compliance

PDF/UA and WCAG answer different questions about the same document. PDF/UA asks, can assistive technology parse this file? WCAG asks, when it can, is what's inside truly usable? Neither question is optional, and neither standard makes the other redundant.

The organizations that get this right stop debating which standard applies and start building workflows where both get checked. Structure first, content second. That sequence matters because a broken structural foundation makes a WCAG review pointless. You can't assess user experience in a file a screen reader can't navigate.

Start with your existing PDF library. Run a structural conformance audit against PDF/UA before touching content criteria. Find out where the tag failures, reading order problems, and missing metadata live. Then work through WCAG success criteria on documents that pass.

Audit both. Fix systematically. Make accessible authoring the default so the next batch of documents doesn't start the cycle again.

This content is for informational purposes only and does not constitute legal advice. WCAG is a technical standard; legal obligations vary by jurisdiction and context. The EAA is implemented through national laws, and compliance obligations vary by member state. Consult qualified counsel for legal guidance.