Published

EPUB accessibility under the EAA starts in the file, but it does not end there

W3C’s EAA mapping and EPUB accessibility guidance show a practical workflow: build an accessible EPUB, attach the right metadata, and stay honest about what storefronts and reading systems still control.

By Rex Publishing

Too many accessibility discussions still collapse into a false shortcut: make the EPUB file compliant and assume the rest of the market will take care of itself. That is not how the workflow works.

W3C’s EPUB Accessibility - EU Accessibility Act Mapping makes the useful point plainly. The European Accessibility Act covers products and services that include ebooks, dedicated reading software, digital rights management software, and ecommerce. The same note says it aims to show how the EPUB standard meets the technical requirements related to ebooks. For Rex readers, the practical lesson is that accessibility work belongs in the EPUB file, but not only there.

What the W3C mapping changes in practice

The W3C note does more than wave at compliance. It says EPUB Accessibility 1.1 addresses four key areas: WCAG conformance, discoverability of accessibility features, specific EPUB accessibility requirements, and evaluation plus conformance reporting for accessible EPUB publications.

That matters because it pulls accessibility out of a narrow file-conversion mindset. A usable workflow has at least three layers:

  • The EPUB file itself, where structure, navigation, alt text, reading order, and semantic markup live.
  • The metadata and distribution layer, where accessibility details have to travel beyond internal production notes.
  • The downstream delivery layer, where reading systems, DRM behavior, and storefront presentation still affect what the reader actually gets.

If a team only fixes the first layer, it has not finished the job. If it ignores the first layer and hopes metadata will compensate, it has not started the job properly either.

What belongs inside the EPUB

W3C’s EPUB Accessibility Techniques 1.2 stays grounded in production details. Its techniques cover the practical work teams already know they should be doing, but often handle inconsistently under deadline pressure.

  • Navigation: the techniques call for table-of-contents order that matches the publication’s linear order and for EPUB landmarks that help users move through the book.
  • Headings and titles: the document emphasizes publication and document titles plus heading structures that reflect the real hierarchy.
  • Descriptions: non-decorative images need alternative text descriptions that do actual explanatory work.
  • Language and text basics: language identification and clean text encoding are part of accessibility, not optional cleanup.

None of that is glamorous, but that is exactly the point. Accessibility failures usually come from ordinary workflow slippage, not from a lack of abstract principles.

Why metadata is part of compliance work, not a separate afterthought

The same W3C techniques document includes a distribution section that says publishers should include accessibility metadata in distribution records. It also includes accessibility metadata in the EPUB package document so the information remains attached to the publication itself.

That split is easy to miss, and expensive to miss. File-level metadata helps the publication stay self-describing. Distribution metadata helps retailers, libraries, aggregators, and other downstream partners surface those accessibility features to real users.

W3C also points directly to ONIX accessibility metadata in this workflow. That is why accessibility teams, production staff, and metadata staff cannot treat their work as separate lanes. If the accessible properties never leave the EPUB and reach distribution records, discoverability still breaks.

We covered that metadata handoff in more detail in our guide to accessibility metadata in ONIX workflows. The EAA mapping makes the same operational point from the standards side: discoverability is part of accessibility.

Where teams should stay careful

The strongest part of W3C’s mapping is also where publishers can overread it. The note argues that EPUB meets the technical requirements related to ebooks, but it does not say that an EPUB file alone solves every accessibility obligation across the chain.

That caution matters for at least three reasons:

  1. Reading systems still matter. A strong EPUB can still reach a user through software that handles features badly.
  2. Storefront and ecommerce presentation still matter. Accessibility information has to be displayed and communicated downstream, not just stored upstream.
  3. Fixed-layout limitations are real. W3C notes that fixed-layout EPUBs can be produced with a good level of accessibility, but some accessibility requirements cannot be met because users cannot freely change graphical formatting in the way they can with reflowable publications.

That is the honest posture for small and mid-sized publishers: build the strongest accessible EPUB you can, transmit its properties clearly, and do not pretend the file solves platform behavior that sits outside the file.

Why this is operationally urgent now

BISG’s Accessibility Working Group frames the issue as a supply-chain problem, not just a standards exercise. BISG says the group exists to amplify trusted guidance from organizations including W3C, DAISY, and Benetech while improving discoverability, reducing compliance risk, and supporting library and public-sector sales.

Its February 2026 survey announcement says the industry is still working through friction in creating, delivering, receiving, and supporting accessible digital products. That is a useful reality check. The bottleneck is rarely just “make a better EPUB.” It is usually the handoff between editorial, production, metadata, distribution, and downstream display.

A workable checklist for Rex readers

If your team needs a practical EAA-facing workflow, start here:

  1. Build accessibility into authoring and EPUB production. Do not leave headings, navigation, language tagging, and image description work until final QA.
  2. Validate the EPUB as an accessibility file. Treat evaluation and conformance reporting as release work, not optional documentation.
  3. Carry accessibility metadata into the package document and distribution records. Make sure the file and the commercial metadata agree.
  4. Check downstream display. Verify how accessibility information appears in the channels that matter for your sales mix.
  5. Flag exceptions honestly. If a fixed-layout title or platform limitation leaves gaps, say so internally before the title hits the market.

The useful shift is procedural, not rhetorical. The EAA is easier to manage when teams stop treating accessibility as a vague legal cloud and start treating it as coordinated EPUB, metadata, and distribution work.

If you need help tightening that workflow, see our ebook QA workflow checklist guide or contact Rex Publishing.