What’s the Big Deal about  EPUB 3.3?

A perennial standard just got better than it’s ever been

The EPUB standard for e-books traces its history back to its predecessor standard, OEB, which was released in 1999—the previous millennium. Other things new that year: the euro, Bluetooth, the iBook, the TiVo, Napster, the Sopranos, and SpongeBob SquarePants. Some people reading this weren’t even born then.

It has steadily evolved over the past two and a half decades, having been renamed EPUB in the version released in 2007; work continued when it moved to the W3C, the Worldwide Web Consortium, in 2017. The current generation is EPUB 3, the latest version of which is the recently published EPUB 3.3.

You could be forgiven for thinking “What? Another update to EPUB? What’s the big deal?”

EPUB 3.3 Is a Really Big Deal!

EPUB 3.3 is different from its predecessors in many important ways, including what may strike you as inconsistent with what I just wrote: unlike many of its predecessors, it does not make the previous version of EPUB obsolete. One of the most fundamental requirements in the charge to the EPUB Working Group by the W3C was that the new version had to be backward compatible.

There are millions of EPUBs in the supply chain and e-book ecosystem now. It would have been a disaster if the new spec made them invalid: the devices that enable us to read EPUBs and the systems that deliver them to us were not about to re-engineer themselves to handle two mutually incompatible versions of EPUB, and publishers were not keen to update all the EPUBs they have already published. Thankfully, most EPUBs are now some version of EPUB 3, and most reading systems, aggregators, and retailers (yes, even Amazon) are built to understand EPUB 3.

Because EPUB 3.3 is backward compatible, any valid EPUB 3 is conformant to EPUB 3.3. While EPUB 3.3 offers some things earlier versions didn’t, nobody is forced to reengineer their systems to be able to handle it.

So Then What’s the Big Deal?

The most obvious change is that the structure of the specification documentation is completely different. Earlier versions of EPUB were single-document specifications. They focused mainly on what is called, in tech-speak, “authoring”: how an EPUB 3 is created, what it consists of, and what the rules are.

The EPUB 3.3 Recommendation has completely restructured and rewritten all that, and more. It consists of three documents:

• EPUB 3.3, how EPUBs should be structured and encoded, the successor to the previous specs.
• EPUB Reading Systems 3.3, how the systems and software that render the EPUBs and deliver them to readers should interpret the spec.
• EPUB Accessibility 1.1, how to ensure that the resulting EPUB is properly accessible to people with disabilities.

And all these specifications have been written in a much clearer, more logical way than the earlier specs had been. They are meant to be read (by anybody), not to make your eyes glaze over. See for yourself.

Now We Know It All Works

“It all works? Duh!” you say. What? We didn’t know that before?

Well, of course, everything in the earlier specs was expected to work, and the near-universal success of EPUB in all those years is evidence that it worked. But it wasn’t all tested formally and systematically before the spec was published.

I don’t mean to denigrate the earlier specs. I was a part of most of those working groups, most of the participants of which were way more technical than I am (I’m not a developer), and who worked very hard to make sure we were getting things right.

But one of the big benefits of becoming part of the W3C is what is known as “horizontal review”: nothing can be published as an official W3C Recommendation until it has passed review for its accessibility, security, privacy, internationalization, and alignment with the web architecture. Of course, all that is reviewed in the development of the spec, but to pass horizontal review, it has to be reviewed by people in those specific areas of the W3C, not the EPUB Working Group itself. It’s a very rigorous, technical review by experts, and it almost always results in some refinements until the spec passes muster.

The EPUB 3.3 Working Group did much more thorough and systematic testing than had been done for previous versions; that ensures that everything in the spec actually works. Plus, the working group has to demonstrate that every feature of the spec has at least two independent implementations, outside of the working group. That confirms two important things about each individual feature: obviously, independently confirming that it works, but also demonstrating that at least two parties deemed it worth their time and effort to implement that feature. One of the problematic things about some of the earlier EPUB specs is that there were features that virtually nobody implemented or that the working group thought better of in hindsight. That creates a very awkward situation: you don’t want to take them out of the successor spec in case somebody does implement them (not just in testing but in the real world). So there are aspects of EPUB 3.3 that are explicitly discouraged due to insufficient implementation, but they can’t be removed, or it wouldn’t be backward compatible.

EPUB 3.3 Is Now a Global Standard

You may not have noticed that, so far, I’ve referred to earlier versions of EPUB as “specifications,” whereas EPUB 3.3 is a recommendation. The earlier specs were standards in the sense that they were (and still are) authoritative, widely used, and relied upon, but they didn’t have the status of a formal, global W3C Recommendation.

In one sense, that may seem a distinction without a difference. EPUB 3.3 is still fundamentally our tried-and-true EPUB. But being a formal W3C Recommendation gives it an official status that is particularly important to some organizations, institutions, and even countries, who need that formal status to build their own requirements on it.

It’s beyond semantics. Being a recommendation (colloquially referred to as a “rec”) means it has gone through that formal technical review, including horizontal review, and passed. Even more important, recommendations can only be published by W3C Working Groups. There are groups within the W3C—the many community groups, for example—that don’t require their members to have formally joined the W3C as members. Only W3C members plus very few invited experts, allowed to participate for significant reasons, can be members of a working group. To do so, the working group members have to certify that they and the organizations they represent (including organizations like Google, Apple, and Microsoft, all very active in the W3C) have agreed that they relinquish any patent claims to any contributions they make to the resulting recommendations.

That is a very big deal because W3C Recommendations are free of cost to everybody and free to use by anybody without fear of being accused of patent infringement. That goes way beyond open access or open source (which are also good things, in my view). A recommendation is radically open, safe, and free for anybody to use.

Get It Right, and You’ve Got Accessibility Nailed

EPUB 3 has always been the best format for accessible publications. It amazed me, when it was first being developed, that the DAISY Consortium—the global advocacy organization and provider of resources and guidance for accessibility, and a major contributor to EPUB all these years—retired its own XML format, DTBook (still in use in some areas, like K–12 education), to put their stamp on EPUB 3 as the best format for accessible publications.

But the truth is that it was still possible to create an EPUB 3 that wasn’t fully accessible. The spec in no way impeded accessibility, but it left enough wiggle room that the majority of EPUBs would pass EPUBCheck while lacking such essentials as image descriptions. All EPUB specs, including the EPUB 3.3 Recommendation, make distinctions between things that must be done and things that should be done. The lack of a “should” doesn’t invalidate an EPUB, and we don’t want it to. We want as many e-books to be EPUBs as possible and as close as they can be to being a truly accessible EPUB. An overly strict standard rarely gains traction in the marketplace.

As I mentioned, earlier versions of the EPUB spec incorporated aspects of accessibility, but the EPUB 3.3 version actually includes a self-contained EPUB Accessibility 1.1 Recommendation that makes what needs to be done for an EPUB to be accessible far clearer and more explicit. Beyond the rec, there are supplementary specifications and guidance documents in the W3C, providing techniques for the best ways to accomplish those things. They also provide greater detail about accessibility metadata.

What has gotten commercial book publishers’ attention is the European Accessibility Act (EAA), which requires that all e-books sold in the EU be accessible by June 2025. But the EAA applies to any digital resources, not just books; it doesn’t spell out exactly what a book being accessible means. The good news: if your e-books conform thoroughly to EPUB Accessibility 1.1, they are considered accessible by the EU. Before the EPUB Working Group published the EPUB 3.3 Recommendation, they did a mapping from all the specs in the rec to the requirements of the EAA to determine that a properly made EPUB 3.3 would be saleable by EAA standards.

EPUB 3.3 Is Ready for Prime Time at the Get-Go

There is often a lag time between when a new specification is issued and when the ecosystem is sufficiently updated to enable it to work. Especially in the case of EPUB, its ecosystem is very extensive: think not just of all the EPUB reading systems, and all the aggregators, but all the publishers, and the vendors who produce EPUBs for most publishers, all of whom have sophisticated systems and workflows built around EPUB. In the past, even for relatively minor updates, it has taken quite a while for the ecosystem to get fully caught up.

That’s largely not the case with EPUB 3.3, thanks to the extensive and very public process of updating the spec in the W3C (where all such work is open to public view) and to the thorough and systematic testing I described earlier. Most significantly, this meant that EPUBCheck, the system that virtually all those parties use to ensure that an EPUB is valid, was updated along the way as EPUB 3.3 was being finalized. So, upon the release of EPUB 3.3, the latest version of EPUBCheck was released to validate EPUBs to it. And that, in turn, has been implemented by virtually all the recipients of EPUBs, so EPUB 3.3s can be validated right away.

We now have a global standard for EPUB, EPUB 3.3, that has been significantly improved over previous specs without breaking compatibility with earlier versions of EPUB 3 and thoroughly documented and tested, providing more comprehensive guidance to accessibility than we’ve ever had before, and for which the EPUB ecosystem is ready. We’re good to go, folks!

About the Author

Bill Kasdorf

Principal, Kasdorf & Associates

Bill Kasdorf is the principal of Kasdorf & Associates LLC, a consultancy focusing on editorial and production workflows, XML/HTML/EPUB content modeling, standards and best practices, and accessibility. He is also the founding partner of Publishing Technology Partners. Active in the W3C Publishing@W3C activity, Bill is the W3C global publishing evangelist. He cochairs two NISO Working Groups and is an active member of SSP, BISG, IPTC, and the DAISY Consortium. Recipient of the SSP Distinguished Service Award and the BISG Industry Champion Award, he is general editor of the Columbia Guide to Digital Publishing, serves on Learned Publishing’s editorial board, and is a columnist for Publishers Weekly.