WCAG 2.2 and PDFs: What Changed and What You Need to Do

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.