WCAG 2 for PDF Accessibility

WCAG (Web Content Accessibility Guidelines) is the dominant standard for web accessibility, and it applies to PDFs too, perhaps surprisingly to teams that think of PDFs as "not web." Regulators in the EU (EAA), the US (ADA, Section 508), Canada (AODA), and elsewhere increasingly treat PDFs as web content for accessibility purposes. This guide covers what WCAG 2 means for PDFs in 2026.

WCAG basics

WCAG 2 is structured around four principles, the POUR model:

Perceivable: users can perceive the content (alt text, captions, contrast).
Operable: users can navigate (keyboard, focus, time limits).
Understandable: content is readable and predictable (language, error handling).
Robust: content works with assistive tech (valid markup, semantic structure).

Each principle has guidelines; each guideline has success criteria at three levels: A (basic), AA (standard target for most regulations), AAA (highest, often not achievable for all content).

In 2026, AA is the common target for compliance.

How WCAG applies to PDFs

WCAG is web-oriented; PDF has its own structural model. The PDF-specific guidance is captured in PDF/UA (ISO 14289), which translates WCAG concepts into PDF specifics.

A PDF that conforms to PDF/UA generally meets WCAG 2 AA's PDF-relevant criteria. The two standards are intentionally aligned.

See PDF UA accessibility standard explained and PDF accessibility guide.

The core PDF accessibility requirements

To meet WCAG 2 AA for a PDF, you need:

Tagged structure: a structure tree that describes headings, paragraphs, lists, tables, figures, links.
Reading order: logical, matching what a sighted reader experiences.
Alternative text for images and meaningful figures.
Sufficient color contrast: 4.5:1 for normal text; 3:1 for large text and graphical objects.
Language metadata: document-level language declared; spans for content in different languages.
Title and metadata: document title, not just filename.
Bookmarks for documents over a handful of pages.
Form fields with labels that screen readers can announce.
No flashing content that could trigger seizures.
Color not the only conveyor of information (charts with patterns, not just color codes).

Tagged PDFs

The core: the PDF's structure tree. A heading is tagged <H1>; a paragraph <P>; a list <L> with <LI> items; a table <Table> with <TR> and <TD>.

Screen readers walk the tree to present the content semantically. Without tags, they fall back to reading order heuristics, which fail on multi-column layouts, sidebars, and complex structures.

For an introduction, see tagged PDF vs untagged PDF and accessibility tags in PDF explained.

Reading order

Reading order is the logical sequence in which content should be consumed:

Main story before sidebars.
Captions after figures.
Footnotes after the body of the page or at the end.

Reading order is set by the order of elements in the structure tree, not by their position on the page. Many PDFs have correct visual order but wrong reading order; the screen-reader experience is jumbled.

Tools to fix: Acrobat Pro's Reading Order panel; PAC 2024 for diagnosis.

Alt text

Every meaningful image needs alt text:

Charts, diagrams, photos, decorative banners.
Logos: "Acme Corp logo".
Decorative-only images: marked as "Artifact" (not announced to screen readers).
Complex figures (graphs with data): brief alt plus a longer description, or a data table alternative.

For figures that convey information not in the surrounding text, alt text needs to capture the information.

Color contrast

WCAG 2 AA requires:

4.5:1 for normal text against its background.
3:1 for large text (18pt or 14pt bold).
3:1 for graphical objects (icons, chart lines).

Tools: WebAIM's contrast checker; Adobe's built-in contrast checker; many designer tools have plugins.

Common PDF failures:

Light gray text on white.
White text on light yellow.
Charts with only color to distinguish series.

Language

A screen reader's pronunciation depends on language settings. PDFs need:

Document language (in metadata) set, e.g., en-US.
Language spans for embedded foreign content (a French quote in an English document).

Without these, English screen readers pronounce French as if it were English, badly.

Title

The PDF's title (in metadata, not the filename) is what a screen reader announces when opening:

Set the title to the human-readable document title.
Configure the viewer to show title in the title bar instead of filename.

In Acrobat: Document Properties > Initial View > Show Document Title.

For more, see how to edit PDF metadata.

Bookmarks

For PDFs over a few pages:

Generated from heading structure automatically by many tools.
Provide a navigation tree for sighted and screen-reader users.
Should match the document's heading hierarchy.

See how to add bookmarks to PDF and how to create bookmarks from headings.

Forms

Accessible PDF forms:

Every field has a tooltip (acting as the label).
Tab order matches visual order.
Required fields are marked.
Validation messages are clear.
No timing constraints that punish slower users.

For more, see making a PDF fillable and PDF form field types explained.

Tables

Tables need:

<Table>, <TR>, <TD>, <TH> structure.
Header cells (<TH>) marked.
Row and column scope where applicable.
Caption (or summary) for complex tables.

Many tools produce tables that look right visually but lack structure markup. Verify.

Lists

Lists need:

<L> tag with <LI> children.
<Lbl> for the marker (bullet or number).
<LBody> for the content.

Faux lists (paragraphs with manual bullets typed) are not lists to a screen reader.

Headings

Headings should:

Be tagged <H1> through <H6>.
Follow a logical hierarchy (no skipping from H1 to H3 without an H2).
Match the document's visual outline.

Headings drive screen-reader navigation (jump from heading to heading). A document with no real headings is exhausting to navigate.

Authoring tools

For producing accessible PDFs:

Word with proper styles: built-in accessibility features; "Save as PDF" with Accessibility Tags option.
InDesign: rich accessibility features; tags configurable.
LaTeX: accessibility tooling is improving (tagged PDF output in 2024+).
Google Docs: basic tagging on export.

The principle: structure your source document semantically (use heading styles, not just bold; use list styles, not manual bullets). Tags follow from semantic source.

Remediation tools

For existing PDFs that need accessibility added:

Adobe Acrobat Pro: Accessibility tools, Reading Order, Make Accessible action.
CommonLook PDF: industry-leading remediation tool.
axesPDF: focused on accessibility.
PDF Accessibility Checker (PAC 2024): free; validates against PDF/UA and matched WCAG criteria.

Remediation is significantly more work than authoring accessibility correctly upfront.

Validation

Tools to check WCAG compliance for PDFs:

PAC 2024: free; comprehensive PDF/UA checking.
Acrobat's Accessibility Check: built-in; less thorough than PAC.
axesCheck.
veraPDF: open-source PDF/UA validator.

Validation tools catch the mechanical issues (missing alt text, untagged content). They don't replace human review (is the alt text good? is the reading order really logical?).

Common gotchas

Tagging looks right but isn't. The Tags tree shows <H1> and <P> but the structure tree positions are wrong. Reading order is off.

Image of text. A logo with text in it; alt text needs to include the text content.

Auto-generated tags from messy source. Word documents with manual formatting (instead of styles) produce wrong tags. Fix the source.

Color contrast on charts. Series distinguished only by color. Add patterns, labels, or shape variation.

Multi-column layouts. Reading order jumps right when it should go down. Common in newsletters and magazines.

Forms with no tooltips. Labels visible on screen but not associated with the form field.

Decorative images announced. A decorative banner reads "logo banner" repeatedly. Mark as Artifact.

Legal implications

Various jurisdictions:

EU: European Accessibility Act (EAA), in force 2025-2026. Many private-sector services must be accessible.
US: ADA (interpreted by courts), Section 508 (federal contracts).
Canada: AODA (Ontario), provincial equivalents.
UK: Equality Act, plus public sector regulations.
Many others: similar trajectories.

PDFs distributed by covered entities should meet accessibility requirements. Inaccessibility has been the basis of lawsuits in the US specifically.

Practical recipe

For producing WCAG 2 AA-conformant PDFs:

Author in Word, InDesign, or similar with semantic styles.
Add alt text to every image at source.
Set document language, title, and metadata.
Export with accessibility tagging enabled.
Validate with PAC 2024.
Manual review: reading order, alt-text quality, form labels.
Test with a screen reader (NVDA free, JAWS, VoiceOver).
Iterate.

For existing PDFs needing remediation:

Run PAC 2024.
Open in Acrobat Pro Accessibility tools.
Fix tagging, reading order, alt text, language.
Re-validate.

For browser-based PDF assembly that preserves accessibility tags (combining tagged PDFs, splitting), Docento.app and similar local tools work without uploading.

Takeaway

WCAG 2 for PDFs is essentially PDF/UA: a tagged structure, alt text, proper reading order, sufficient contrast, and language metadata. Built into the authoring step, accessibility costs little; added after, it costs a lot. As regulations tighten around the world, the inflection toward accessible-by-default PDF authoring is overdue. See also PDF accessibility guide, PDF UA accessibility standard explained, and tagged PDF vs untagged PDF.