Image description: An e-reader sits on a stack of physical books with a pair of earbuds resting on top, the screen showing a page of accessible text — the everyday surfaces where EPUB3 has to work.

Reading Time: 12 minutes

EPUB3 is the format publishers will be measured against when the European Accessibility Act begins to be enforced in earnest. It is also the format that the WIPO Marrakesh Treaty and the Accessible Books Consortium use to move accessible books across borders, and the format that screen-reader users, low-vision readers and print-disabled students expect when they buy an ebook. Unlike PDF, EPUB3 is reflowable, semantic and accessible by design — but only if the publisher actually ships the metadata, the markup and the navigation that the spec calls for. A file with the .epub extension is not the same thing as an accessible EPUB.

This primer is for publishers, editorial-technology teams and accessibility leads inside ebook retailers. It walks through what the EPUB3.3 specification requires, which accessibility-metadata fields the schema.org and EPUB Accessibility 1.1 specifications expect you to populate, which reading systems actually render EPUB3 well in 2026, where the EAA compliance pressure on retailers is biting, and how the Marrakesh ecosystem rounds out the picture. It is deliberately concrete: by the end you will know what to ask your conversion vendor for, what to put in your metadata, and what to test before you upload to a retailer.

What EPUB3 requires

EPUB3 is a W3C Recommendation. The current stable version is EPUB 3.3, published as a W3C Recommendation in May 2023 after the format graduated from the IDPF into the W3C. EPUB 3.3 consolidated a series of incremental revisions, made accessibility a first-class requirement rather than an optional companion document, and tightened the relationship between EPUB and the wider open-web platform — an EPUB is, at its core, a packaged ZIP archive of HTML, CSS, SVG and supporting resources, governed by an OPF (Open Packaging Format) manifest and a navigation document.

For the file itself to be accessible, EPUB 3.3 expects publishers to use semantic HTML throughout. That means real headings in document order (h1 through h6), real lists (ul, ol, dl), real tables for tabular data with proper thead, tbody, th scoping, and the EPUB-specific structural semantics vocabulary (epub:type) for marking up chapters, sections, footnotes, page-list entries, glossary terms and the dozens of other publishing roles the spec recognises. A book whose chapter headings are visually styled paragraphs without any heading element is not accessible — a screen reader cannot jump to the next chapter, a refreshable braille display cannot announce the chapter break, and a reflow engine cannot generate a table of contents on the fly.

Language tags are non-negotiable. Every EPUB must declare a primary language in the OPF package document, and any inline content in a different language must be marked with the appropriate lang and xml:lang attributes. Text-to-speech engines and screen readers switch voice profiles on the basis of these tags; a French paragraph inside an English book that is not language-tagged will be read out in an English voice with predictably comic, and exclusionary, results. The same rule applies to direction (dir) for mixed left-to-right and right-to-left content.

Every EPUB must ship a navigation document — a single XHTML file referenced from the OPF as the navigation document, containing at minimum a table of contents (nav epub:type=“toc”), and ideally a page-list (nav epub:type=“page-list”) mapping print-page numbers to in-book locations and a landmarks list (nav epub:type=“landmarks”) flagging the cover, the body matter, the index and other discoverable surfaces. The page-list is the feature that allows a student using an accessible ebook to follow the page references in a printed syllabus without falling out of sync with classmates reading the paper edition.

Images need alt text for every image that conveys content. Decorative images take alt="" and an aria-hidden=“true” if appropriate, but content images — diagrams, photographs in a photography book, maps, illustrations in a children’s book — need real descriptions. Complex images such as scientific diagrams need long descriptions, either inline via aria-describedby pointing to a description element, or via the epub:type=“describedFootnote” pattern. Maths in any book that goes beyond casual mention should be encoded as MathML, not rasterised as PNG screenshots. MathML is the only encoding that lets a screen reader speak an equation, that lets a refreshable braille display render it in Nemeth or Unified English Braille, and that lets a reader resize the equation without pixelation.

EPUB3 also supports media overlays — synchronised text and pre-recorded audio narration, defined in SMIL files that map each text fragment to a time-range in the audio. A media-overlay EPUB lets a low-literacy reader, a reader with a cognitive disability, or simply a commuter follow the highlighted text as a human narrator reads it aloud. The SMIL approach predates the modern wave of high-quality TTS, but the two technologies are complementary: media overlays remain the gold standard for children’s books, language-learning titles and accessibility-funded conversions, while TTS handles the long tail.

Accessibility metadata: the schema.org / A11y-meta layer

An accessible file that does not advertise itself as accessible is invisible to the readers who need it. The EPUB Accessibility 1.1 specification, published as a W3C Recommendation alongside EPUB 3.3, mandates a set of metadata fields that must appear in the OPF package document. These fields draw on the schema.org accessibility vocabulary — the same vocabulary used by Bookshare, the DAISY Consortium, Benetech, the Accessible Books Consortium, and the major retailer feeds.

The required and strongly-recommended properties are:

  • schema:accessMode — the modalities the content uses (textual, visual, auditory). A novel is textual; an illustrated children’s book is textual,visual; a media-overlay audio-text book is textual,visual,auditory.
  • schema:accessModeSufficient — the modality combinations that are sufficient to consume the content on their own. A novel typically lists textual as sufficient (because everything important is in the text). A graphic novel without alt-text descriptions cannot honestly claim textual alone is sufficient.
  • schema:accessibilityFeature — the discrete features present, drawn from a controlled vocabulary: structuralNavigation, alternativeText, longDescription, tableOfContents, readingOrder, printPageNumbers, mathML, synchronizedAudioText, highContrastDisplay, displayTransformability, captions, transcript, and several more.
  • schema:accessibilityHazard — disclosure of any content that may trigger seizures, motion sickness or other reactions: flashing, noFlashingHazard, motionSimulation, noMotionSimulationHazard, sound, noSoundHazard. If the book is hazard-free, say so explicitly.
  • schema:accessibilitySummary — a human-readable, plain-language summary of the accessibility of the publication, written for the end reader: “This publication conforms to WCAG 2.1 Level AA. All images have alternative text. Mathematical equations are encoded in MathML. Page numbers reflect the print edition.”
  • a11y:certifiedBy, a11y:certifierCredential, a11y:certifierReport — if a third party has certified the file against EPUB Accessibility 1.1, who certified it, what credential they hold, and a link to the published certification report.
  • dcterms:conformsTo — the conformance profile the publication meets, expressed as a URL pointing to EPUB Accessibility 1.1 conformance criteria (WCAG 2.1 Level AA, or in newer files Level AAA where claimed).

These fields are not paperwork. They flow into retailer catalogues, into the Accessible Books Consortium’s global accessible-book database, into Bookshare’s discovery, into school-procurement catalogues and into the EAA reporting templates that retailers now have to maintain. The European standard EN 17161 — accessibility through “design for all” — references this metadata layer, as does the Functional Accessibility Evaluation criteria used by the ACE accessibility checker maintained by the DAISY Consortium.

Reading systems: what actually renders EPUB3 in 2026

The single most quoted complaint in publisher accessibility teams is that the same EPUB renders differently on different reading systems. The complaint is true and the gap matters. A file that scores perfectly on the DAISY ACE checker may still fail to expose its navigation document on a popular consumer reader, or fail to speak its MathML on a major iOS app. The gap between what the spec defines and what the reading system implements is the reason a publisher’s accessibility workflow has to include real-device testing, not just file-level validation.

Thorium Reader, maintained by the EDRLab consortium, is the reference free desktop reader for accessible EPUB3 in 2026. It implements EPUB 3.3 and EPUB Accessibility 1.1 thoroughly, exposes the navigation document, the page-list and the landmarks list, renders MathML, supports media overlays, and integrates with the operating-system text-to-speech and the major screen readers (NVDA on Windows, VoiceOver on macOS, Orca on Linux). Many publishers use Thorium as their accessibility-acceptance reader: if a file works in Thorium, it is well-formed and conformant.

VoiceDream Reader (now part of the Voice Dream stable acquired in 2022) remains the leading iOS app for print-disabled readers who want premium TTS voices and fine-grained control over speech parameters. It opens EPUB3 reliably, respects language tags for voice switching, supports custom fonts and dyslexia-friendly typography, and integrates with the Bookshare and Learning Ally catalogues. For students and adult readers with dyslexia, low vision or blindness, VoiceDream is often the default app.

VoiceOver Books — Apple’s built-in audiobook experience inside the Books app, paired with iOS VoiceOver — is the route most blind iOS users actually take. It handles EPUB3 well, exposes the navigation document to VoiceOver, speaks alt text, switches voices on language tags, and surfaces media overlays. Where Apple Books still struggles is MathML rendering inside complex STEM titles and consistent exposure of the page-list when the user is navigating by print-page reference.

Apple Books on macOS, iPadOS and iOS is the broadest consumer reading system for EPUB3 in the western market and renders most accessibility features competently. Its limitations are in the long tail: certain media-overlay edge cases, certain rare MathML constructs, and inconsistent behaviour with very large page-lists.

The conspicuous exception in 2026 remains Amazon Kindle. Amazon does not natively support EPUB3 inside the Kindle ecosystem; instead it ingests EPUB and converts it on upload into its proprietary KF8 / KFX formats. The conversion preserves text, basic structure and many images, but it does not preserve all accessibility metadata, does not render MathML reliably, drops media overlays entirely, and has historically not exposed the schema.org accessibility-metadata fields to users searching the Kindle catalogue. Publishers shipping into Amazon often maintain a parallel KF8/KFX accessibility workflow, but the practical effect is that the most accessible EPUB3 a publisher can produce is partially degraded the moment it reaches the largest English-language ebook retailer. The EAA pressure described in the next section is the first regulatory lever capable of moving that needle.

EAA pressure on ebook retailers

The European Accessibility Act (Directive (EU) 2019/882) entered into application on 28 June 2025, and ebooks are explicitly inside its scope. Article 4 of the directive obliges economic operators to ensure that the products and services they place on the EU market comply with the accessibility requirements set out in Annex I. For ebooks and dedicated ebook software, the Annex I requirements include: ensuring that ebooks (and the software needed to access them) support text-to-speech, allow users to adapt presentation (font size, contrast, line spacing), expose the metadata necessary for assistive technology to navigate the content, allow synchronised audio and text where present, provide non-text content with alternatives, and prevent ebook protection measures from blocking accessibility features.

In practice, the Annex I list maps almost one-to-one onto the EPUB Accessibility 1.1 conformance criteria. A publisher that ships EPUB3 files conforming to EPUB Accessibility 1.1 — with the schema.org metadata properly populated and a certifier’s statement — has a strong presumption of conformity with the Annex I obligations. A publisher shipping unstructured PDF or DRM-locked formats that block screen-reader passthrough is squarely in non-compliance.

The compliance pressure does not fall only on publishers. It falls equally on retailers, which the directive treats as economic operators in their own right. National market-surveillance authorities began their first round of EAA compliance inspections during the second half of 2025 and through 2026, and ebook retailers have been an early focus because the catalogues are public, the metadata is machine-readable and the non-compliance is easy to evidence. Retailers operating in the EU now generally require publishers to deliver EPUB Accessibility 1.1-conformant files, to populate the schema.org metadata fields, and to provide a certification statement; some have begun rejecting unconformant uploads at ingest. For platforms with significant proprietary-format dependencies — Amazon Kindle, in particular — the EAA has forced a public commitment to closer EPUB3 fidelity, though the engineering work to deliver it is still in progress.

For publishers, the operational consequence is unambiguous: ebook accessibility metadata is now a publishing requirement, not a nice-to-have. Production teams that previously ran accessibility as a separate downstream conversion now build it into the source workflow.

The Marrakesh Treaty and Accessible Books Consortium ecosystem

EPUB3 sits inside a wider treaty and infrastructure ecosystem that publishers should understand because it changes what “accessible book” means at scale. The Marrakesh Treaty — the WIPO Marrakesh Treaty to Facilitate Access to Published Works for Persons Who Are Blind, Visually Impaired, or Otherwise Print Disabled, adopted in 2013 and now in force in more than 100 contracting parties including the EU and the United States — creates a copyright exception that allows authorised entities to produce, distribute and cross-border-exchange accessible-format copies of published works for the benefit of beneficiary persons, without needing rightsholder permission for each transaction.

The Treaty is implemented in EU law via Directive (EU) 2017/1564 and Regulation (EU) 2017/1563, and in the United States via the Marrakesh Treaty Implementation Act of 2018, which amended Title 17. The operational infrastructure is run by the Accessible Books Consortium (ABC), a WIPO-led alliance of organisations representing visually impaired people, libraries serving them, publishers and standards bodies. ABC operates the Global Book Service, a cross-border lending and exchange platform through which authorised entities — typically national libraries for the blind, organisations such as Bookshare in the United States and the RNIB in the United Kingdom, and equivalent national agencies across Europe and the Global South — share accessible files.

The format of choice for these exchanges is EPUB3 with full accessibility metadata, and for older or scanned material the DAISY 2.02 and DAISY 3 formats that EPUB3 effectively succeeds. A book that a French publisher has produced as an EPUB Accessibility 1.1-conformant title can, in principle, be shared via the ABC Global Book Service with a print-disabled reader in Kenya, India, Argentina or any other contracting party, without renegotiation. The Treaty does not change the publisher’s commercial position — it operates on the accessible copy specifically, for the beneficiary population specifically — but it does dramatically enlarge the reading public for any well-formed accessible ebook a publisher ships.

For publishers, the practical link between the EAA layer and the Marrakesh layer is the same metadata block. The schema.org accessibility properties, the EPUB Accessibility 1.1 conformance claim, and the certification report you produce for EAA compliance are the same artefacts that allow your file to flow into the ABC Global Book Service and the wider network of authorised entities. Ship the file once, in the right format, with the right metadata, and the same artefact serves the EU compliance regime and the global accessible-reading public at the same time.

A practical workflow for publishers

The implementation pattern that production teams settle on, once the dust clears, is built around four anchors. Source accessibility: the source manuscript is structured (real headings, real lists, real tables, language-tagged) before any conversion happens, so the EPUB conversion preserves structure rather than reverse-engineering it. Conversion to EPUB 3.3: the conversion tool — whether in-house, a vendor pipeline, or an open-source toolchain such as the DAISY Consortium’s tooling — produces EPUB 3.3 with semantic markup, a navigation document, a page-list where the title has a print equivalent, alt text on all content images, MathML where mathematics appears, and media overlays where the editorial brief calls for them.

Metadata population: every file leaves production with a complete schema.org accessibility metadata block — accessMode, accessModeSufficient, accessibilityFeature, accessibilityHazard, accessibilitySummary, conformsTo — and where the title is certified, the a11y:certifiedBy/Credential/Report fields are populated against the certifier of record (commonly Benetech’s certification programme, the DAISY Consortium, or a national equivalent). Validation and real-device testing: every file is validated against EPUBCheck and the DAISY ACE accessibility checker, and a representative sample is tested on Thorium, Apple Books, VoiceDream and the retailer-specific reading systems the title will be sold through.

The cost of doing this is real, but it falls quickly with practice and tooling. The cost of not doing it — EAA non-compliance fines, retailer rejection at ingest, missing readers in the Marrakesh network, and the wider reputational cost of shipping ebooks that disabled readers cannot use — is now firmly higher. EPUB3 accessibility is no longer a specialist sub-discipline at the end of the production pipeline. It is the spec.