WCAG 2.2 and the EAA: What Documents Must Do Now

Two developments have changed the compliance landscape for digital content: the publication of WCAG 2.2 as the current W3C recommendation, and the European Accessibility Act, whose requirements for many products and services began applying across EU member states in June 2025. Together they move accessibility from a public-sector concern to a mainstream commercial obligation, and they reach well beyond websites into the documents, e-books and learning content that organizations publish every day.

Operations and publishing managers we work with often know the headlines but not the specifics: which new success criteria actually apply to a PDF or an EPUB, what the EAA means for a publisher outside Europe, and where to start when the backlog runs to thousands of files. This post sets out the substance of both developments and a roadmap we use with clients to turn them into a manageable programme.

WCAG 2.2 builds on 2.1 rather than replacing its structure, adding nine new success criteria and retiring one. The additions focus heavily on users with motor and cognitive disabilities: keyboard focus must remain visible and not be hidden behind sticky headers or overlays, interactive targets need a minimum size, functionality must not depend on dragging, help mechanisms must appear consistently, and authentication must not rely on remembering passwords or solving puzzles.

The retired criterion is 4.1.1 Parsing, now considered obsolete because modern assistive technologies no longer depend on it. Everything that conformed to WCAG 2.1 remains relevant; 2.2 is additive. For teams that built their checklists around 2.1, the update is an extension of existing practice rather than a rewrite, but procurement language and legal references are steadily shifting to 2.2, so conformance claims and policies need updating now.

Static documents are less affected by WCAG 2.2 than interactive applications, but they are not exempt. Interactive PDFs with form fields must respect Redundant Entry, meaning users should not be forced to re-enter the same information within a process, and link or button targets in any paginated digital format benefit from the Target Size minimum. E-books and e-learning packages delivered through web readers inherit the full set, because the reading system and the content are judged together.

The deeper effect is indirect. WCAG 2.2 is being folded into the harmonized European standard EN 301 549, which is the technical yardstick regulators and customers use for EAA conformity. Documents assessed under that umbrella will face the 2.2 criteria wherever they apply, so building them into authoring templates and QA checklists now is considerably cheaper than retrofitting them after an audit finding later.

The EAA, Directive (EU) 2019/882, is not a web law. It covers products and services including e-commerce, banking services, transport information and, significantly for publishers, e-books and dedicated reading software. Obligations began applying to new products and services placed on the EU market from 28 June 2025, with limited transition arrangements for some existing services and a notable exemption regime for microenterprises.

The practical consequence is that accessibility has become a market-access condition. A publisher anywhere in the world selling e-books into the EU must meet the requirements, and trading partners increasingly push the obligation down the supply chain through contracts. In our conversations with publishers, EAA clauses now appear routinely in vendor agreements, which means typesetters, conversion houses and content developers are being asked to warrant accessibility rather than treat it as an optional extra.

Enforcement sits with national market surveillance authorities and penalties vary by member state, but the more immediate pressure is commercial: retailers and aggregators are beginning to require accessibility metadata and conformance declarations before listing titles. Waiting for a regulator to write is the wrong trigger; the realistic deadline is the next contract renewal or distribution agreement that lands on your desk with accessibility warranties attached.

For PDFs, the operational standard remains PDF/UA, with WCAG 2.2 governing how the document behaves in a browser or viewer context. For EPUB, the EPUB Accessibility specification maps conformance to WCAG levels and adds publishing-specific requirements such as accessibility metadata. For e-learning, SCORM or xAPI packages are web content in every meaningful sense and should be authored and tested against WCAG 2.2 Level AA directly.

The common thread is that format-specific standards inherit from WCAG, so a single organizational benchmark, WCAG 2.2 Level AA, can anchor policy across all content types. What differs by format is the production technique and the testing toolchain, which is why a compliance programme needs format specialists, not just a policy document and goodwill. Teams that treat a PDF, an EPUB and a course as interchangeable deliverables usually discover the gaps during an audit, at the most expensive possible moment.

We recommend treating compliance as a programme with four phases. First, inventory: catalogue your content estate by format, volume, business value and renewal cycle. Second, baseline: audit representative samples against WCAG 2.2 AA and the relevant format standard to understand defect patterns rather than auditing everything. Third, remediate strategically: fix high-traffic and legally exposed content first while correcting templates and authoring practices so new content is born accessible. Fourth, sustain: build accessibility checks into production gates and procurement language.

Sequencing matters more than speed. Organizations that start by remediating their archive often exhaust budget before fixing the production line, so the backlog regrows. Fixing the pipeline first stops the bleeding; the archive can then be remediated in priority order, or on demand as documents are requested, which is a defensible approach under most regulatory frameworks when documented honestly in an accessibility statement.

The failure modes we encounter are consistent: relying solely on automated checkers, which catch only a fraction of WCAG failures; treating accessibility as a one-time project rather than a production discipline; and writing accessibility requirements into contracts without acceptance criteria, so vendors deliver files that technically validate but practically fail. Each of these pitfalls is avoidable with modest process changes, provided they are made early rather than after delivery.

If you act on one thing this quarter, make it this: pick your ten most important documents, test them against WCAG 2.2 AA with both an automated tool and a screen reader, and use the findings to brief your template owners and vendors. That single exercise converts abstract regulation into a concrete defect list, and it gives you a realistic basis for budgeting the wider programme.