Skip to content
wcagc
←Back to blog
EAAe-booksdigital-publishingEPUBEN 301 549

EAA compliance for e-books and digital publishing

What the EAA requires for e-books and e-readers: accessible EPUB files, metadata, text-to-speech, and how to check conformance.

P

Pavel Charkasau

EAA e-books compliance is now a legal duty, not a nice-to-have: the European Accessibility Act names both e-books and e-readers directly. The Act lists "e-books and dedicated software" as a covered service and "e-readers" as a covered product (Directive (EU) 2019/882, Article 2), and it has applied across EU member states since 28 June 2025 (European Commission). If you publish, distribute, or sell e-books to consumers in the EU, three things fall in scope: the e-book files themselves, the reading software or device, and the store where people browse and buy.

For the files, the Act sets out specific duties in Annex I: content must be navigable and reflowable, must not block assistive technology, must carry accessibility metadata, must pair synchronised audio with text when audio is present, and must not let digital rights management (DRM) switch accessibility features off (Annex I, Section IV). In practice that means well-structured, accessible EPUB with real metadata. The W3C maps every one of those clauses to EPUB Accessibility 1.1, so building to that standard is the clearest route to conformance. Automated checks catch the machine-detectable defects; human review handles the rest. Here is what applies, and how to verify it.

Does the EAA apply to e-books and publishers?

Yes. The EAA is Directive (EU) 2019/882, and Article 2 lists the products and services it covers. "E-books and dedicated software" is named as a service, and "e-readers" as a product (Article 2). The Act defines an e-book as "a service, consisting of the provision of digital files that convey an electronic version of a book," together with the software used to read them (Article 3(41)). An e-reader is "dedicated equipment, including both hardware and software, used to access, navigate, read and use e-book files" (Article 3(42)).

Because both the file and the reading tool are named, the obligation spreads across the supply chain. Publishers produce the files; distributors and retailers place them on the market; device and app makers build the reading software. Each economic operator carries duties for the part it controls. And because e-book stores are also e-commerce services under the Act, the storefront where a reader searches, previews, and checks out has to be accessible in its own right, on top of the books it sells.

The reason the EU regulated this at all is written into the law. Recital 41 notes that divergent national rules "would make it difficult for publishers... to benefit from the advantages of the internal market" and "could create interoperability problems with e-readers" (Recital 41). One EU-wide bar, rather than 27 different ones, is the point.

What are the EAA accessibility requirements for e-books?

Annex I, Section IV sets out the service requirements specific to e-books. There are six, and they read as a practical brief for a production team (Annex I, Section IV):

  • Synchronised audio and text. When an e-book contains audio in addition to text, it must provide the two in sync, so a reader can follow along by ear and eye at once.
  • No interference with assistive technology. The digital files must not prevent assistive technology from operating properly, so a screen reader can read the whole book.
  • Access, navigation, and flexible layout. The reader must be able to reach the content, move through it, and change how it is presented, including text and layout.
  • Alternative renditions and interoperability. The content must work with a range of assistive technologies so it stays perceivable, operable, understandable, and robust.
  • Discoverability through metadata. Accessibility information must be provided as metadata, so a buyer can tell before purchase whether a title meets their needs.
  • DRM must not block accessibility. Digital rights management measures must not switch off accessibility features.

The W3C has mapped each of these clauses to a concrete EPUB feature (EPUB Accessibility – EU Accessibility Act Mapping). Synchronised audio maps to EPUB media overlays. Navigation and reflow map to a proper table of contents, page-list navigation, and WCAG reflow. Interoperability maps to WCAG 2 conformance. Discoverability maps to accessibility metadata, and the DRM duty maps to the standard's distribution rules. Meeting EPUB Accessibility 1.1 covers the set, which is why most of the industry has settled on it as the working target.

What counts as an accessible EPUB, in practice?

An accessible EPUB is a well-structured document, not a scanned image with a cover. The details that matter most:

  • A logical reading order and heading structure. Content flows in the order a person reads it, with nested headings (not text styled to look like headings).
  • Real navigation. A table of contents and page-list that assistive technology can use to jump around.
  • Declared language. The primary language is set in the package metadata, and passages in another language are marked.
  • Meaningful alt text on images. Informative images carry descriptions; decorative ones are marked so a screen reader skips them.
  • Accessibility metadata. schema.org fields such as accessMode, accessibilityFeature, accessibilityHazard, and a human-readable accessibilitySummary in the package document, plus the matching ONIX fields that travel with the book into retail catalogues.

One honest limitation: fixed-layout titles — comics, illustrated children's books, heavily designed art and cookery books — cannot fully satisfy the reflow and presentation-flexibility duties, because the format pins content to the page (EPUB Accessibility – EAA Mapping). That does not exempt them; it means the accessible features you can provide (alt text, structured navigation, honest metadata) matter more, and your accessibility statement should record what the format cannot do.

How does this connect to WCAG and EN 301 549?

The EAA states outcomes; it does not spell out the technical tests. For the digital surfaces (the e-book store, the reading app, the web content), conformance runs through the harmonised standard EN 301 549, which incorporates WCAG 2.1 Level AA for web content (EN 301 549 v3.2.1, ETSI). Meeting the relevant clauses gives a presumption of conformity with the law.

For the e-book files themselves, EPUB Accessibility 1.1 references WCAG as its content-conformance backbone and adds the publishing-specific pieces (metadata, media overlays, distribution) that a general web standard does not cover. So the two standards divide the work cleanly: EN 301 549 (WCAG 2.1 AA) for the app and store, EPUB Accessibility 1.1 for the book. A version of EN 301 549 referencing WCAG 2.2 is expected, but until it is formally cited in the Official Journal, 2.1 AA is the legal bar.

How do publishers check and document e-book accessibility?

Work in two layers, and treat metadata as a third track that is easy to forget.

Layer one: automated testing. Run your storefront and reading app through a scanner built on a real rules engine, covering the journeys that matter: search, product page, sample preview, checkout, and library. This clears the high-frequency, machine-detectable defects fast: missing labels, low contrast, missing page language, duplicate IDs, basic ARIA mistakes. For the EPUB files, an accessibility checker (such as the open-source Ace by DAISY) validates structure and flags missing metadata before a title ships.

Layer two: manual review. A person checks what a machine cannot judge: does a screen reader read the whole book in the right order? Is every image's alt text actually useful? Can you buy a title using the keyboard alone, with a visible focus indicator throughout? Does focus return sensibly after a preview dialog closes?

How much does automation catch on the web side? Deque's analysis of more than 2,000 audits found automated testing identified about 57% of issues by volume; measured as a share of WCAG success criteria, automation lands closer to 30% (Deque, 2021). Either way, a large part of conformance only shows up under human review. Scan first to clear the obvious defects, then run a structured manual pass with our WCAG checklist.

Then document it. An honest accessibility statement records your conformance level, lists known limitations (fixed-layout titles, for example), gives a plan and timeline, and offers a feedback contact. Documented effort is what the law asks for, not a flawless score, and no tool can promise the score. In April 2025 the US Federal Trade Commission approved a final order requiring the overlay vendor accessiBe to pay $1 million over claims that its widget could make any site WCAG compliant (FTC, April 2025). Full conformance needs human review and real fixes in your own files and code.

Frequently asked questions

Does the EAA apply to self-published authors?

The duties fall on economic operators placing e-books on the EU market: publishers, distributors, and the platforms that sell them. A self-published author is usually working through a retailer or aggregator, which shares responsibility for accessible files and metadata. The narrow microenterprise exemption for service providers (fewer than 10 staff and turnover or balance sheet of €2 million or less) can apply to a very small operation, but it does not remove the value of accessible files that a compliant store still expects.

What file format do accessible e-books need?

The EAA is format-neutral, but accessible EPUB is the practical answer, because EPUB Accessibility 1.1 maps to every e-book clause in the Act. A structured EPUB with headings, navigation, declared language, alt text, and accessibility metadata is the clearest route. Fixed-layout titles cannot fully meet the reflow duty; document that in your accessibility statement.

Is accessibility metadata really required?

Yes. Annex I, Section IV requires e-books to be "discoverable by providing information through metadata about their accessibility features." In practice that means schema.org fields inside the EPUB and matching ONIX fields in the trade feed, so a buyer can see a title's accessibility before purchase.

Do e-readers and reading apps have to be accessible too?

Yes. E-readers are named as a covered product, and the Act requires a built-in synchronised text-to-speech capability and an interface that works with assistive technology. Reading apps fall under the "dedicated software" part of the e-book service definition and must meet WCAG 2.1 AA via EN 301 549.

Can an overlay or widget make an e-book store compliant?

No. Automated tools and overlays catch part of the picture, but screen-reader behaviour, keyboard operation, meaningful alt text, and accessible file structure all need human work. The FTC's 2025 order against accessiBe followed claims that a widget alone could make a site WCAG compliant.

See where your publishing surfaces stand

The fastest way to turn EAA e-books compliance from a worry into a plan is to see your actual issues. Run a free scan of your e-book store and reading app to find the machine-detectable problems, then validate your EPUB files and work through the manual checklist for the rest. You will know what to fix, in what order, and what to put in your accessibility statement.

Pavel Charkasau, founder, wcagc.com. Last updated 11 July 2026.

Sources