WCAG 2.2 and PDFs: What Changed (Compliance Guide)

PDF documents remain one of the most common ways to share reports, forms, and manuals. With the release of WCAG 2.2, document owners need to look beyond traditional PDF accessibility checks and address new success criteria that affect how people interact with digital content. This guide explains the changes that matter most for PDFs and outlines practical steps to keep your documents compliant.

New success criteria that matter for PDFs

Focus Not Obscured (2.4.11)

When a user navigates a PDF form or interactive document with a keyboard, the focused element must remain visible. In long forms or documents with fixed headers, footers, or side panels, the active field can become hidden behind other content. Authors should test tab order and ensure that no interface component hides the element that currently has keyboard focus.

Drag Movements (2.5.7)

Any action that requires dragging, such as signature fields or slider controls inside a PDF, must offer an alternative that does not rely on dragging. Users with motor impairments may not be able to perform a drag gesture. Provide buttons, numeric inputs, or other single-pointer alternatives for every drag-based interaction.

Target Size Minimum (2.5.5)

Interactive targets in PDFs, including buttons, checkboxes, and links, should be at least 24 by 24 CSS pixels where possible. Small touch targets are difficult for users with tremors or limited precision. Review form fields and navigation elements to confirm they meet the minimum size or have enough spacing so users do not accidentally activate adjacent controls.

Accessible Authentication (3.3.8)

If a PDF includes a login step or secure form, avoid cognitive function tests such as CAPTCHAs, puzzles, or memorized passwords as the only method of authentication. Offer alternatives like biometric verification, email magic links, or device-based authentication. For documents distributed through web portals, ensure the authentication page meets this criterion as well.

Redundant Entry (3.3.7)

Do not ask users to enter the same information twice within a single PDF form session. If a user already provided an address, name, or account number, auto-populate later fields or make them available for selection. Redundant data entry creates fatigue and increases errors, especially for users with cognitive or motor disabilities.

Consistent Help (3.2.6)

When help mechanisms, contact details, or support links appear across a set of PDFs or within a document portal, place them in the same location on each page. Inconsistent placement makes it harder for users to find assistance. A predictable help pattern reduces anxiety and supports users who rely on stable navigation.

What document owners should do

Start by auditing existing PDFs with tools that report WCAG 2.2 issues, not only WCAG 2.1. Update document templates and forms so that interactive elements are large enough, keyboard reachable, and free of redundant steps. Train content creators to avoid drag-only controls and to keep help links in consistent positions. If you publish PDFs through a website, verify that authentication pages and surrounding navigation also meet WCAG 2.2.

Conclusion

WCAG 2.2 does not replace earlier PDF accessibility work, but it adds important requirements for focus visibility, pointer interactions, and user assistance. By reviewing each new success criterion and applying it to your document workflow, you can produce PDFs that are easier to use for everyone.

Related: For the standard itself, see What is PDF/UA? and PDF/UA vs WCAG 2.1 AA.

Sources and references

The 9 new success criteria in WCAG 2.2 — and which ones apply to PDFs

WCAG 2.2 added nine success criteria (two at Level A, four at AA, three at AAA). Not all of them affect PDF documents — some are specific to web interaction patterns. Here is every one, and its relevance to PDF authors:

Success Criterion	Level	Applies to PDFs?	What it means for your documents
3.2.6 Consistent Help	A	Limited	If your PDF contains help mechanisms (embedded instructions, links to support), they should appear consistently. Rare in static documents.
3.3.7 Accessible Authentication	A	No	Applies to login flows. PDFs do not authenticate users.
2.4.11 Focus Not Obscured	AA	No	Applies to interactive focus indicators on web pages. PDF form fields should have visible focus, but this is handled by the PDF reader.
2.5.7 Dragging Movements	AA	No	Applies to drag-and-drop interactions. PDFs do not use drag-and-drop.
2.5.8 Target Size (Minimum)	AA	Yes — form fields	Interactive elements like form checkboxes and buttons must be at least 24×24 CSS pixels. In PDF terms: make form fields large enough to tap or click reliably.
3.3.8 Accessible Authentication (Minimum)	AA	No	Same category as 3.3.7 — login flows only.
2.4.12 Focus Not Obscured (Enhanced)	AAA	No	Enhanced version of 2.4.11.
2.5.8 Target Size (Enhanced)	AAA	Yes	Enhanced version — 44×44 pixel target size for form elements.
3.3.9 Accessible Authentication (Enhanced)	AAA	No	Enhanced version of 3.3.7.

The practical takeaway: Of the nine new WCAG 2.2 success criteria, only 2.5.8 (Target Size) meaningfully affects PDF documents, and even then only for interactive forms. The other criteria are web-interaction-specific. For static PDF documents — reports, forms, agendas, statements — your compliance work is essentially unchanged. Focus on PDF/UA-1 tagging and validation, which covers the document-structure requirements that WCAG 2.2 inherits from 2.1 AA unchanged. See our PDF/UA vs WCAG comparison for how the two standards fit together.