Digital Publishing & Structured Content

EPUB 3.4 Is Coming: What Publishing Teams Should Test Now

EPUB 3.4 has reached Candidate Recommendation, but that is an invitation to test—not a signal to change every production file. Here is how to learn from the draft without confusing experimentation with readiness.

10 minute read
A blank digital tablet resting on a stack of books and notebooks

Publishing teams have a familiar standards problem: the useful time to investigate a new specification is before it becomes routine, but the safe time to make it a production default is after the surrounding tools and reading systems have caught up. EPUB 3.4 is now in exactly that interval.

On July 21, 2026, the World Wide Web Consortium invited implementations of EPUB 3.4, EPUB Reading Systems 3.4, and EPUB Accessibility 1.2. W3C is accepting comments on the Candidate Recommendation package through October 19. That makes the next few weeks valuable for publishers, conversion vendors, education teams, and scientific-content producers that can test real files and report concrete interoperability problems.

The practical takeaway

Keep EPUB 3.3 as the production baseline unless your distribution partners explicitly support something else. Run an EPUB 3.4 pilot now on copies of representative titles, record reading-system results, and feed genuine specification problems back to W3C before the review window closes.

Candidate Recommendation is a testing milestone, not a ship date

W3C describes the current documents as work in progress that may still be updated, replaced, or superseded. Candidate Recommendation means the working group believes the design is mature enough for implementation experience. It does not mean every reading app, retailer, library platform, authoring tool, conversion service, validator, or accessibility checker accepts every new feature.

The tooling gap is visible today. W3C calls EPUBCheck the industry’s de facto conformance checker, but the current production-ready EPUBCheck release validates EPUB 3 files against EPUB 3.3 rules. The project has a separate EPUB 3.4 milestone in progress. A clean result from today’s production validator is therefore useful evidence about the stable baseline—not proof that a file exercises the 3.4 draft correctly.

Treat version declarations, feature support, and distributor acceptance as separate questions. A file may be structurally sound, use a draft feature exactly as specified, and still fail in a reading system or ingest pipeline that has not implemented it. Conversely, a familiar file can render well in one app while carrying incomplete metadata or nonconforming markup. The pilot needs evidence from all three layers.

Which EPUB 3.4 changes deserve editorial attention?

The EPUB 3.4 change log is the best starting point because it identifies changes that could affect publication conformance. The draft adds AVIF and JPEG XL as core image media types, adds Opus in an MP4 container as a core audio type, advises against variable-bitrate MP3 files with media overlays, and reorganizes fixed-layout guidance to include roll layouts. It also moves several older mechanisms into outdated or deprecated categories.

One proposed change did not survive: ordinary HTML syntax is not being added. After surveying more than 100 people across publishing and reading-system roles, the working group decided to keep XHTML as the EPUB content format. Production teams should not read “built on web technologies” as permission to package the same forgiving HTML they might publish to a website. XML well-formedness, namespace handling, and EPUB’s package rules still matter.

EPUB Accessibility 1.2 introduces a smaller set of changes with large workflow implications. Its current draft makes accessModeSufficient required and accessMode recommended, adds an optional a11y:contactEmail for accessibility questions, and defines the exact metadata pattern for an EPUB Accessibility 1.2 conformance claim. These fields should come from an evaluated publication, not a default export template. Metadata that says a reader can consume a book textually is a product claim about the complete publication, including meaningful alternatives for visual or audio content.

A five-part EPUB 3.4 publishing pilot

Step 1

Build a small but difficult test shelf

Do not start with the cleanest reflowable novel. Choose five to ten titles that expose the real pipeline: long-form prose, tables, mathematics, footnotes, bidirectional or vertical text, fixed layout, media overlays, rich image descriptions, and a title with extensive cross-references. Include one known-good EPUB 3.3 file as a control. Preserve the source packages and production outputs so every result can be reproduced.

Step 2

Create a change-to-test matrix

For each 3.4 change you plan to explore, name the source change, expected package markup, validator expectation, reading-system behavior, fallback strategy, and pass criterion. For AVIF or JPEG XL, test image decoding, dimensions, color, zoom, offline use, and thumbnail generation—not only whether the file opens. For media overlays, compare timing and navigation with constant- and variable-bitrate audio.

Step 3

Audit accessibility metadata from evidence

Review the entire publication against the current EPUB Accessibility 1.2 draft before asserting conformance. Confirm that sufficient access modes describe what a reader can actually use, hazards are accurate, features exist throughout the book, and the accessibility summary explains material limitations. If you add a contact address, decide who monitors it and how reported problems enter the correction workflow.

Step 4

Test reading systems as products, not screenshots

Use a documented matrix of devices, operating systems, reading apps, assistive technologies, and distribution routes that reflects your actual audience. Check navigation, reading order, search, text resizing, themes, footnote return paths, image alternatives, text-to-speech, media controls, and offline behavior. A visual spot check on one desktop reader cannot reveal whether semantics or navigation survive elsewhere.

Step 5

Separate specification defects from implementation defects

When a result differs from the expectation, reduce it to the smallest reproducible test. Compare the authoring requirement with the corresponding reading-system requirement and the W3C testing and exit criteria. Record the exact app and version. Report specification ambiguity or missing coverage through the W3C issue process; route product-specific failures to the relevant vendor.

Use evidence gates for the production decision

A standards pilot should end with a decision package, not a folder of screenshots. For every proposed feature, summarize the editorial benefit, source-system cost, validation status, reading-system coverage, distributor acceptance, accessibility effect, fallback behavior, and rollback path. Classify the result as ready, restricted to named channels, experimental, or blocked.

  • Ready: the feature is stable in your source and conversion workflow, accepted by required distributors, and usable in the supported reading-system matrix.
  • Restricted: the feature works only in a defined product, channel, or controlled learning environment with an explicit support boundary.
  • Experimental: the feature is being tested against the draft and must not enter customer-facing production files.
  • Blocked: validation, accessibility, interoperability, or distribution evidence is insufficient.

Version the matrix alongside the conversion configuration. Retest when the W3C draft changes, EPUBCheck adds 3.4 support, a distributor changes its ingest rules, or a major reading-system release lands. That record keeps a promising lab result from becoming an undocumented production dependency six months later.

What publishing teams should do now

Read the three Candidate Recommendation documents as a set. Keep the stable production path intact. Choose a representative shelf, identify only the changes that solve a real publishing problem, and test those changes through validation, distribution, rendering, and accessibility review. If the pilot uncovers a reproducible standards problem, the current review period is the right time to contribute it.

This is also a useful moment to repair problems that are independent of 3.4: unstable identifiers, broken cross-references, duplicated reference lists, ambiguous headings, incomplete alternatives, and undocumented transformations. A draft standard cannot compensate for a weak source layer. Before conversion, teams can use a prepublication citation-status check to confirm that the references entering a new edition still point to current evidence.

For structured publishing teams

Clean the source layer before the format changes.

Superscriptify helps teams align citation callouts and references in JATS XML and repair source-heavy Word and PowerPoint files before content moves into downstream publishing workflows.

Explore JATS reference alignment

Sources and further reading

This article provides general technical and editorial information, not legal or accessibility-conformance advice. Verify the final W3C specifications and the current requirements of every distributor and jurisdiction relevant to your publication before release.