What Does EPUB 3.3 Mean For Accessibility?
The publishing community eagerly awaits the new version of the EPUB standard, EPUB 3.3, the related EPUB 1.1 accessibility specification and the updated version of EPUBCheck. We asked EPUB 3.3 editor and DAISY developer Matt Garrish; “What does this mean for accessible publishing?’
Can We Expect Major Changes For Accessibility?
Neither the EPUB 3.3 nor the Accessibility 1.1 revisions represent major changes. Most of our efforts are focused on taking the work we’ve already done and moving the documents through the W3C process to make formal recommended specifications of them (i.e., to be fully recognized by W3C membership). EPUB 3.2 was published by the W3C publishing community group, so those documents did not have any formal standing (they didn’t have to go through W3C membership votes, they didn’t have to show independent implementations, etc.). So, EPUB 3.3 will formalize the standard.
So, EPUB 3.3 Doesn’t Look That Much Different?
Actually, EPUB 3.3 does not look at all like EPUB 3.2 from a document structure perspective. EPUB 3.2 was made up of five specifications (not including Accessibility 1.1 which is a separate specification):
- EPUB 3.2
- EPUB Packages 3.2
- EPUB Content Documents 3.2
- EPUB Open Container Format (OCF) 3.2
- EPUB Media Overlays 3.2
The authoring requirements from these specifications have now been merged into a single specification called EPUB 3.3, which is available in draft form right now at: https://www.w3.org/TR/epub-33/
There aren’t any major new features in EPUB 3.3, although there are a couple of new core media types, which are formats that you can use in your content without fallbacks. These are the WebP image format and the Opus audio codec.
EPUB 3.3 Splits Authoring From Reading Systems
The reading system requirements have now been split out into a new specification called, appropriately enough, EPUB Reading Systems 3.3 which is also a working draft: https://www.w3.org/TR/epub-rs-33/
Splitting authoring from reading systems was designed to make it easier for people to find only the requirements that apply to them. No more sifting through requirements. We’ve also done a lot of restructuring of sections to ease the burden of reading them. Now that we don’t have concepts split across multiple documents, we can group requirements more logically (for example, fixed layouts requirements used to be split across the Packages and Content Documents specifications, as part were about how to author the content and part were about how to identify the metadata in the package document).
Separating authoring and reading systems also has the side benefit of having fewer documents to take through the W3C process and better isolation when it comes to showing how the specifications can be implemented.
What Stage of the Process Have You Reached?
We’re just getting ready to wrap up the working draft stage and move to a candidate recommendation (the links above won’t change when we do). What this means is that our focus will change from revising the technical details of the specifications to showing that the specifications can be implemented by authors and reading systems. There is a testing task force working on creating tests for all the normative requirements and then during the CR stage we’ll be looking for implementations to prove the tests.
For readers who aren’t completely familiar with EPUB 3, we maintain an overview document (https://www.w3.org/TR/epub-overview/). This isn’t only about what has changed in 3.3 but provides a general introduction to the state of the format as of this revision.
How Does this Affect the EPUB Accessibility 1.1 Specification?
The Accessibility 1.1 revision is very similar to EPUB 3.3 in that there are not a lot of major changes from 1.0. The new version incorporates the text improvements that were made to EPUB 1.0 as part of making it an ISO standard (ISO/IEC 23761:2021), but those changes were editorial in nature (i.e., the IDPF and ISO specifications read differently, but have the same base requirements).
The most significant change that people will need to be aware of is that we’re now allowing conformance to adapt to the latest versions of WCAG 2 as they become recommendations (the Accessibility 1.0 specification only allowed conformance to WCAG 2.0). You still have to minimally meet WCAG 2.0 Level A to meet the base requirements of our specification, but publishers are now encouraged to conform to the latest recommended version of WCAG 2 (which is 2.1 right now, but 2.2 is coming). Level AA conformance is also recommended. This means that there is now a new conformance identifier that publishers will have to use in the metadata that adapts to what WCAG version and level you have met. The details are explained here: https://www.w3.org/TR/epub-a11y-11/#sec-conf-reporting-pub.
Other minor tweaks include the separation of the page navigation and media overlay objectives into separate sections to make them easier to read, but they aren’t different from the 1.0 specification.
Will EPUBCheck be Updated to Support EPUB 3.3?
The next version of EPUBCheck, the free command line EPUB checking tool, will provide complete support for checking conformance to the EPUB 3.3 standard. The Public Beta version is due out shortly.
EPUB 3 has been widely adopted as the format for digital books (ebooks), and this revision continues to increase the format’s capabilities to better support a wider range of publication requirements, including complex layouts, rich media and interactivity, and global typography features. The expectation is that publishers will utilize the EPUB 3 format for a broad range of content, including books, magazines, and educational, professional, and scientific publications. (Overview introduction taken from EPUB 3.3 working draft)
