The EPUB 3 Working Group has published EPUB 3.3, EPUB Reading Systems 3.3 and EPUB Accessibility 1.1 as W3C Recommendations, as part of the Digital Publishing activity.

EPUB defines a distribution and interchange format for digital publications and documents. The EPUB format provides a means of representing, packaging, and encoding structured and semantically enhanced web content — including HTML, CSS, SVG, and other resources — for distribution in a single-file container.

The content specification, which is what publishers, creators, or authors are really interested in, is now separate from the reading system specification that is of primary interest for implementers only. Editorial changes made the documents more readable.

Accessibility of EPUB publications was an essential part of the group’s activity. As a result, the EPUB Accessibility specification has been updated and, for the first time in the history of EPUB, is now an integral part of the EPUB Standard. Furthermore, the EPUB Accessibility specification is compatible with the European Accessibility Act whose influence will be significant on Digital Publishing in the years to come.

Finally, please note that this edition of EPUB is dedicated to Garth Conboy, who was one of the original designers of EPUB, and an initiator of the W3C Working Group which produced these new specifications. He is, and will remain, greatly missed.

Please read our Press Release to learn more about this achievement.

The EPUB 3 Working Group has published three Proposed Recommendations today for EPUB 3.3. This technology defines a distribution and interchange format for digital publications and documents. The EPUB format provides a means of representing, packaging, and encoding structured and semantically enhanced Web content — including HTML, CSS, SVG, and other resources — for distribution in a single-file container.

The three Proposed Recommendations are:

• The EPUB 3.3 specification defines the authoring requirements for EPUB Publications and represents the third major revision of the standard.
• The EPUB Reading Systems 3.3 specification defines the conformance requirements for EPUB 3 Reading Systems — the user agents that render EPUB Publications.
• The EPUB Accessibility 1.1 specifies content conformance requirements for verifying the accessibility of EPUB Publications. It also specifies accessibility metadata requirements for the discoverability of EPUB publications.

Comments are welcome through 15 May 2023.

The EPUB 3 Working Group has just published the Working Group Note of EPUB Type to ARIA Role Authoring Guide 1.1. This document provides guidance for publishers looking to move from the use of the EPUB 3 epub:type attribute to ARIA roles for accessibility.

The epub:type attribute has evolved to aid publisher workflows. It has limited use enabling reading system behaviors outside of some core functionality of EPUB (identifying navigation elements and enhancing media overlay documents). Although it was hoped the attribute would also expose information to assistive technologies, in practice it does not. The primary purpose of the ARIA role attribute, on the other hand, is to expose information to assistive technologies. It is not to facilitate user agent behaviors. This guide addresses key authoring differences to be aware of when migrating to ARIA roles from the epub:type attribute, or when using both attributes together. The goal is to help publishers avoid the pitfalls of applying ARIA roles like they would epub:type semantics and breaking the reading experience for users of assistive technologies.

The EPUB 3 Working Group is pleased to announce that three of our documents have now progressed to Candidate Recommendation: EPUB 3.3, EPUB 3.3 Reading Systems, and EPUB Accessibility 1.1. We encourage implementers to review the specifications and test.

EPUB 3.3

EPUB 3.3 is completely backwards compatible with previous versions of EPUB 3, meaning that current EPUB 3 files in your systems likely already meet EPUB 3.3 requirements. The working group has made some changes to the specifications to introduce more clarity to the documents as well as introduce some new content types and recommendations around areas previously underspecified.

New Media Types

EPUB 3.3 introduces two new media types:

• WebP, a modern image format for the web, which allows for smaller file sizes with the same quality as JPEG or PNG
• OPUS, an open source audio codec also designed for the web, with streaming, storage, and a wide range of support for different bitrates and sampling rates

The addition of these media types brings EPUB closer to modern web standards, especially as digital publishing becomes more mature. We look forward to seeing implementations taking advantage of these additions.

Changes to the Package File

We have added additional control in the package file to allow for the proper rendering of bidirectional texts in fields like title.

New Document Structure

EPUB 3.3 features a major revision to how the EPUB specification is structured. Previously, EPUB 3.2 was structured into 5 different documents, which contained requirements for both content authors and reading systems:

• EPUB 3.2
• EPUB Packages 3.2
• EPUB Content Documents 3.2
• EPUB Open Container Format 3.2
• EPUB Media Overlays 3.2

In EPUB 3.3, we have organized the content of those 5 documents into 2, dividing them by their audience:

• EPUB 3.3 Core
• EPUB 3.3 Reading Systems

Core covers all of the requirements for content authors, while reading systems are contained in the second document. While understanding both documents is helpful, it is now much easier to find information depending on your use case, as each document holds all of the pertinent requirements for its audience.

In addition to revising the document structure, we have also gone through both documents thoroughly to address any editorial issues. Many requirements or informative sections have been revised to focus on real-world implementation practice, or just to clarify any confusing language. A number of notes have been added to both documents to ensure key points are clarified as well.

We have also removed some features from the core specifications that are mentioned in the satellite specifications. Mentions of multiple renditions have been move to the Multiple Renditions document, as well as text-to-speech requirements. This is to align the specifications better with real-world implementations of EPUB and reading systems.

Privacy and Security

While EPUB 3 is over 10 years old, this is the first time the specification has been through the W3C Process. Previous versions of the specification have not been through wide review, which was an interesting and enlightening process for the EPUB 3 WG. While EPUB has had a strong focus on internationalization and accessibility, both of which are core to the format, we never reviewed the specifications for privacy and security.

With the help of W3C Privacy Interest Group, EPUB 3.3 and EPUB 3.3 Reading Systems now both have sections focusing on the unique privacy and security concerns in EPUB 3.3. EPUB relies strongly on the security model of the web, but there were also unique circumstances we needed to consider as a transmission and presentation format. Building a threat model for EPUB was an interesting thought exercise, and we strongly recommend implementors review both when reviewing the new version of the specification.

For people new to the concept of a threat model, here are some examples of threats we saw in the EPUB ecosystem:

• Scripting
• Compromised or malicious remote resources
• Phishing/spoofing
• Collection of user data
• User-generated content

It’s important to point out that some of the privacy and security issues in EPUB are not just from the file format, but also from the ecosystem it resides in. Reading systems or other user agents for EPUB should be conscious of privacy and security issues they may introduce in how they build their software.

Testing

As part of CR, we are building a test suite for EPUB 3.3. Reading system implementers are encouraged to run the tests on their systems and report the results back to us. You can find information on EPUB testing on our testing repository.

We look forward to seeing the results of the testing, particularly because we hope to see increased interoperability in the EPUB ecosystem with some of the updates made to the EPUB specification. While very few features have changed, we hope providing clarification might make it easier to understand areas that are under implemented.

Members of the EPUB community are also encouraged to contribute tests of the specifications, but please be sure to follow our contribution guidelines and process.

Under Implemented Features

As part of CR, we have identified some areas of the EPUB specification we believe to be at-risk. At-risk is defined as not meeting the 2-implementation threshold. In EPUB, this means the feature does not appear in more than two different reading system platforms.

Due to the requirements around backwards compatibility, we will not be deprecating any features deemed at-risk. However, if any features tested do not meet the required 2-implementation threshold, we will be labelling them as “under-implemented”.

This is a new classification that we have added to two other classifications already in the EPUB specification:

• Deprecated features - features the working group no longer recommends be used, as they have limited to no support in the market (ex. EPUB switch)
• Legacy features - features we have retained for backwards compatibility with previous versions of EPUB, but may not be supported by reading systems (ex. the NCX file)

In the limited testing we have done so far, we have discovered two features we consider to be potentially under-implemented:

• rendition:flow
• manifest fallbacks

EPUB Accessibility 1.1

The EPUB Accessibility specification has been updated to meet the need of publishers and content creators as they prepare for the European Accessibility Act (EAA). Some of these changes include:

• Allowing EPUB creators to conform to the latest version of WCAG
• New recommendations for page list and page numbering
• refines attributes for accessibility metadata fields

In addition to these changes, editorial changes have also been made to improve the document in alignment with the rest of the specification. We have also added expanded privacy and security sections to the Accessibility specification, which was reviewed alongside EPUB 3.3 and Reading Systems.

What can the community do to help?

First and foremost, review the specification! While in CR we are still able to make some changes, and we appreciate feedback that will help us achieve our goals of improved interoperability and readability of the specification.

Review the test suite, try the tests out, and please report any errors or issues the tests might have. We also would appreciate help with writing new tests, as the specification is still expansive and many areas still require testing.

Lastly, if you are a reading system implementer, run the tests and provide an implementation report. The more results we have, the better. While we need 2 implementations to prove the viability of features, because the digital publishing ecosystem is so big, the more information we have about support for EPUB the better it is for us to make decisions on what features to focus on or improve over time. For potentially under-implemented features, if you happen to be an implementer your feedback is essential.

The EPUB 3 Working Group invites implementations of the following three Candidate Recommendation Snapshots:

• EPUB 3.3 defines the authoring requirements for EPUB publications and represents the third major revision of the standard.
• EPUB Reading Systems 3.3 defines the conformance requirements for EPUB 3 reading systems — the user agents that render EPUB publications.
• EPUB Accessibility 1.1 specifies content conformance requirements for verifying the accessibility of EPUB® Publications. It also specifies accessibility metadata requirements for the discoverability of EPUB publications.

EPUB® 3 defines a distribution and interchange format for digital publications and documents. The EPUB format provides a means of representing, packaging, and encoding structured and semantically enhanced web content — including HTML, CSS, SVG, and other resources — for distribution in a single-file container. A separate overview note gives a more detailed view of the specifications.

The specification represents the third major revision and, in particular, a revision of the EPUB 3.2 document published by the EPUB 3 Community Group. This new version is now on a W3C Recommendation Track. There have been only a few technical additions in the areas of internationalization, security, or core media types. The focus of the Working Group have been to align the specifications with the latest W3C specifications, current usage and practices of the publishing industry, improve the readability of the specification, align the accessibility requirement with the latest Web Accessibility standards as well as the European Accessibility Act, and to work on a comprehensive test suite to improve the interoperability of Reading Systems. Read also the detailed change logs in the documents for further details.

We are pleased to announce the latest production-ready release of EPUBCheck, version 4.2.5, providing support for checking conformance to the EPUB 3.2 family of specifications. This is a maintenance release. Full details and release notes are available at [https://github.com/w3c/epubcheck/releases/tag/v4.2.5.

We are also excited to launch the EPUBCheck website at https://www.w3.org/publishing/epubcheck/. Come here to download the latest release of EPUBCheck and find useful resources about it.

In February of this year, the Publishing@W3C community ran a survey for the publishing industry on the topic of EPUB and the future of publishing. The main focus of the survey was to understand how people are using EPUB, what challenges they face, or what they wish they could do but currently cannot. The other goal of the survey was to understand more about the needs of readers and members of industries like educational publishing.

The survey in total was 85 questions and we received over 250 responses! The Publishing@W3C community would like to thank everyone who responded, with this data we can be much more decisive in determining what the future of publishing looks like.

The full results of the survey can be found here, in this blog post I will share some highlights and interesting findings.

Reading Systems and Readers

Some of the questions in the survey focused on the needs and problems faced by reading system developers and users. We learned that only 5 of 14 respondents have implemented all of the EPUB specifications, with the majority citing a lack of ROI (return on investment) being the reason not to implement outside of the core specification. Another interesting comment was that since many features exist as part of WebAPIs for browser-based renderers, there’s no return on building EPUB-specific functionality.

The most difficult parts of the specification to implement include Media Overlays, Fixed Layout, and Javascript.

The good news is that reading systems are eager for more: 83% reported they’d like to have more conformance information in the specification, and an overwhelming 95% would love to see tests. They’re also interested in accessibility, while only 37% reported they display provided accessibility metadata, 53% of those who do not currently say they plan on doing so in the future.

There are still challenges out there, reading systems are reported to be difficult to do accessibility testing with, interoperability is a huge challenge for publishers and users, as one respondent put it: “EPUB is fine, but reading systems limit it’s potential”. Content creators can’t leverage modern web stack features because of inconsistent/nonexistent support.

EPUB Today

One of the largest sections of the survey focused on how ebook developers and publishers use EPUB. The EPUB specification is quite feature-rich, not counting the satellite specifications, and we wanted to get an idea of exactly how many of those features are used. We also wanted to know how many people made the switch to EPUB3.

72% of those who responded publish in EPUB3, with an additional 20% publishing a combination of EPUB2 and EPUB3. Just over half support a backlist of EPUB2 content as well. Just under half of those who responded still produce PDF content on top of their EPUB content, citing partner requirements and formatting as the main reasons for supporting the multiple formats.

Fixed layout is still the content type of choice for children’s books, graphic novels, and some educational content. When asked why more people do not create high-design reflowable publications instead, respondents cited the need for support of modern CSS layouts like Grid or Flexbox, support for full-bleed images in reflowable books, and cost of production.

A majority of respondents believe EPUB needs more core media types, in keeping with the modern web platform. 74% cited an interest in using scripting (Javascript) in EPUB if it were better supported by reading systems and the specification. Features like user interactivity in quizzes, charts, images and maps were the most popular. MathML is used by a small group of content creators, but many mentioned the need for better support from reading systems.

A big question we wanted to answer was who was using epub:type and how. 79% reported that they do use epub:type, with the most common uses being for document partitions, navigation, divisions, sections, and annotations. The main expectation users had from employing `epub:type` was that assistive technologies would be able to use the types to process the semantic information. The other expectations were for annotations appearance and navigation for reading systems.

Overall, there were no huge surprises in the EPUB ecosystem, with potentially the exception of the usage of epub:type. EPUB3 is a strong format, and while there are many ways we can improve the experience of users and content creators, the foundation we’re working from is solid.

EPUB Tomorrow

As mentioned before, there are still ways to improve EPUB, and we asked the community about what they would like to see in future versions or releases of EPUB. Some of these ideas will be taken to the proposed EPUB3 Working Group and others will be sent to the Publishing Community Group for further discussion and incubation.

When looking at the future of EPUB, we wanted to identify what things people struggled or were completely unable to publish using the format. EPUB is flexible, and many of us have seen it used in amazing ways, but it does not work for every use case, and to understand where we could improve, we needed to know what those use cases were.

When asked what features content creators would like to see supported in EPUB, the top results were Dual Language Support, notifications for readers, background or full bleed images, and more interactive features like testing or map integrations. 63% of respondents expressed an interest in mixing fixed layout and reflowable sections in an EPUB. For those who are keen on the specification, you’ll know this is technically already possible, but has very little implementation.

The last big request for improvement was around data formats and scripting. EPUB3 has long supported javascript as a scripting format, but implementation is mixed at best and the specification does not address it beyond explaining how to reference it in the content documents.

Many things asked for in the survey are features EPUB already supports or theoretically could, but aren’t laid out explicitly in the specification. One of the goals of the new EPUB 3 Working Group is to address those gaps, be they issues with implementations or a lack of clarity in the language of the spec. We look forward to addressing as many of these problems as we can. Of course, if there is anything we’re missing, please feel free to let us know by filing an issue in the GitHub repository.

We want to thank all of the respondents again for their feedback and time, it has been immensely helpful for gaining an understanding of our industry today. We will be in touch with anyone who expressed an interest in doing so, and for anyone who did not have a chance to complete the survey, or would like to know more about it or anything related to Publishing@W3C, please feel free to reach out to us on twitter @w3cpublishing or by email at public-publishing-sc@w3.org.

Securing a strong future for EPUB. Exploring new ideas for every sort of digital publication. Bringing business needs to the technical community: These are the goals of Publishing@W3C. In the last few weeks, we've heard from both the broad digital publishing community and the leadership of the Publishing Business Group. We'd like to share with you our renewed commitment to our mission, and some changes in our organizational structure to better achieve these goals.

Most importantly, thank you to everyone who took the EPUB Survey. We are surprised and delighted that 270 people so far have responded to an admittedly very long survey. Even better, the in-depth and thoughtful responses have provided us with a wealth of information and insight into the needs and wants of the community. EPUB remains critically important to the digital publishing world. If you haven’t yet taken the survey, go to the survey and let us know what you think!

Going forward, we hope to have three groups working on the various facets of digital publishing: 

• An EPUB 3 Working Group to secure the future of EPUB. 
• A Publishing Community Group to explore and incubate new ideas, as well as collect feedback from the broader community. 
• And finally, the Publishing Business Group to advocate for business needs, work on communication and outreach, and coordinate with the other groups. This structure provides many different ways for organizations and individuals to contribute. 

Let’s look at each of these groups in more detail.

EPUB 3 Working Group

We plan to create a new EPUB 3 Working Group, focusing on making EPUB 3 a W3C Recommendation and the continuing maintenance of EPUB 3. The group would be chaired by Wendy Reid (Rakuten Kobo) and Dave Cramer (Hachette).

What is now EPUB originated more than twenty years ago with OEB 1.0. OEB was quite simple: HTML with CSS and a single XML file to describe the metadata. It wasn't even packaged. The packaging mechanism, and the name "EPUB", arrived in 2007. EPUB 3, first released in 2011, added HTML 5 support, audio, video, an ability to “fix” the layout of a page, and so on. EPUB 3 was more powerful, more accessible (thanks to contributions from the DAISY Consortium), and could handle more of the world's languages with better integration of W3C standards. The latest update, EPUB 3.2, was completed only last May by the EPUB 3 Community Group within the W3C. EPUB 3 has been a tremendous success. It is mature, widely adopted around the world, and the foundation of a billion-dollar industry. EPUB is gaining a foothold in the corporate and documentation worlds, and is becoming easier to create. Soon you will be able to export EPUB from most common word processors.

So why do we want to create an EPUB 3 Working Group, and why make a W3C Recommendation for EPUB? In a word, interoperability. Standards are a contract between content creators and reading systems. If I make an EPUB following the standard, your reading system should display it correctly. But, for interoperability to be more than wishful thinking, we need tests. Tests demonstrate that the implementation does what the specification says. Tests are the tool that sharpens both the spec and the reading system. We hope that the much-more-rigorous W3C process will make a cleaner, clearer, more easily-implemented EPUB 3 specification. We hope that the existence of tests will make it easier to demonstrate interoperability, to illustrate when reading systems fall short, and to help those that fall short to catch up. We want EPUB 3 to work predictably everywhere.

We want to make the spec better, yes, but we won't be changing the foundations of EPUB. We are very focused on backward compatibility, as we demonstrated with EPUB 3.2. Every valid EPUB 3.2 file should be valid to the new REC-track EPUB 3 spec unless it uses a feature that was never implemented anywhere. We understand the importance of preserving the existing ecosystem. But we hope to also add a few features that were requested by survey respondents.

Having EPUB 3 as a formal W3C Recommendation also helps us with government adoption of EPUB, and provides a solid foundation for legislation around EPUB’s native accessibility.

We are energized by the enthusiasm of the broad EPUB community, and excited about the future of EPUB 3. Together we can make EPUB even better!

The EPUB 3 and Publishing Community Groups

We are profoundly grateful for the many contributions of the EPUB 3 Community Group over these last several years. Although the new Working Group will take EPUB 3 to REC, that does not diminish the need for the EPUB 3 Community Group. In fact, we hope to broaden the scope of the Community Group to evaluate and incubate new ideas, both for EPUB and for digital publishing in general. Please consider this an invitation to share your exciting ideas about how publishing should evolve!

Community Groups play a critical function in W3C, as the birthplace of new ideas. These ideas need to be examined, incubated, and shared to see if they are both technically viable and serve a real need. If an idea is truly viable, the CG can even create draft specifications, which would then be passed on to the appropriate working group to become W3C Recommendations. This process ensures that we can encourage and maintain broad community participation in the strategic development of Publishing ideas before they are funneled into the formal standards track.

There are many publishing-related community groups that already exist, and we invite you to bring your ideas to the Publishing Community Group as well.

Because of the broader scope of the Community Group, we propose that it be renamed as the Publishing Community Group, and also take over the responsibility of the existing Publishing Community Group. In addition to working on the future of EPUB and digital publishing, be prepared to help with documentation and testing. Like all CG’s, the Publishing Community Group will be open to anyone.

The proposed chairs for the Publishing CG are Mateus Teixeira (W. W. Norton) and Jeff Xu ( Rakuten Kobo).

Publishing Business Group

The Publishing Business Group will serve as a place to organize the community and gain the perspective of the industry. The CG may ask the BG to evolve its ideas to help gain an understanding of the business case behind certain ideas before passing them along, even if the technology seems fantastic. Much of what we have seen from the survey is that there is a need for more information as people grow catalogs of content and consider how to maintain them over the long term. The BG will work on community expansion, communication, and outreach to ensure that people have a place to share and get information both globally and locally.

The Business Group is going to create an EPUB Reading System Bug Tracker in GitHub to catalog the known issues that can be shared among all parties to move toward better implementation and conformance to the EPUB 3 standard.

The BG will continue to be chaired by Liisa McCloy-Kelley of (Penguin Random House), Daihei Shiohama (Media Do), and Cristina Mussinelli (Fondazione LIA).

Publishing Steering Committee

The Steering Committee will continue to coordinate the working group, the business group, and the community group, as well as liaise with other W3C groups. The Steering Committee consists of the chairs of all three groups and representatives from W3C along with other invited members, such as emeritus chairs. This effort will be led by Tzviya Siegman of (Wiley) and Ralph Swick (W3C).

The Publishing Working Group

The Publishing Working Group is nearly finished with its work. The Audiobook specification is a Candidate Recommendation and is in the midst of implementation and testing. The Publication Manifest is also a Candidate Recommendation and will serve as the backbone of audiobooks as well as future derivatives. This group’s charter will expire on July 1, 2020, and the group will disband, after achieving many of its goals. Many thanks to the chairs—Wendy Reid, Tzviya Siegman, and Garth Conboy—as well as all the group’s participants for these great accomplishments.

We Want to Hear From You

We have heard your requests for communication, for participation, for openness, and want to continue to hear from you and to speak with you. If we have not gotten this right, and you would like to see a change in the direction of these plans, there is time to reach out to us. We have started reaching out to the community, group by group, and would like to stress that these decisions are not yet firm. These are proposals based on feedback from our community. Please contact us individually or at public-publishing-sc@w3.org and tell us what you’re thinking!

There are a lot of exciting things happening in the publishing community. We look forward to continuing to work with you. Look for more blog posts from the Publishing@W3C team!

Many thanks to my colleagues on the Steering Committee for their assistance in writing this post, especially Dave Cramer.

See minutes online for a more detailed record of the discussions.

CR publication

The CR, as well as the LPF Note, is planned to be published on Thursday, 2nd of December. Everything has been approved and set up

Testing

• There is an initial systematic (though not necessarily complete) test suite for the API (i.e., the transformation of the manifest into an internal representation, with a number of checks on the fly), including a report page
• It was agreed to create a separate testing repository to collect all these, as well as other possible test suites, in one place
• Other test suites considered are: TOC extraction tests (although that is not a required mechanism), JSON Schema-based tests, behavioral tests.

The next step is to populate these test suites, to have implementers self-report on those.

Meeting schedule for the rest of the year

The last meeting this year will be on the 16th of December.

See minutes online for a more detailed record of the discussions.

CR Approval

There was a Call for Consensus by email on two issues:

• FPWD publication of the Lightweight Packaging Format (LPF)
• Request to advance Audiobooks and the Publication Manifest to CR

Both proposals were accepted and the meeting recorded the positive resolution. The official request for CR should go out to the Director this week.

The rest of the meeting was going into the weeds of how testing will be done, what tests to use and how, how to report, etc.

See minutes online for a more detailed record of the discussions.

Road to CR

The main topic was the last steps to do for going to CR. There is a temporary request that has to be completed, primarily in terms of testing plans. To main issues forward:

• WG members should read the document (and the aforementioned page) to prepare for a CR transition request vote in a week
• The LPF document is almost ready to go, there will be an email request to agree on publishing that document in conjunction with the the CR publications

See minutes online for a more detailed record of the discussions.

Open issues

The group handled some open issues:

• Usage of fragment IDs and repeated URLs: the group agreed that
  1. Fragment identifiers can be used without further ado in the manifest (it was, formerly, disallowed)
  2. While it is recommended not to repeat URL-s for resources in readingOrder or resources, it is not explicitly disallowed any more
• Choosing alternatives: at the moment the document is silent on how the User Agent should choose among several alternatives for a linked resource, if available. It was agreed that this should remain the case for now, future releases, as well as specific documents (including profiles) may add their own rules (e.g., for synchronized media). Future versions of the spec may have a more general mechanism
• Resolving URL prefixes in the manifest: it is possible, in JSON-LD, to add prefixes to the context, and uses that in the form of a CURIE for terms. This is one of the extension mechanism in the publication manifest. The question was whether the simple handling of the manifest (i.e., without a JSON-LD processor) should resolve such prefixes and, as an additional issue, whether the context should include a number of predefined prefixes. The group agreed not to do any of these.
• Cover description: is it always recommended?: this discussion touched upon the role of the description value, with its relationship to an alternate description of an image in HTML. It was agreed that this issue is way too complex for this group as it touches upon the interpretation of WCAG and possibly adding a technique to it. It is not a rule that can be added normatively in the document.

With these handled, it looks like the document is getting to a closure, and will be ready for CR. The group also discussed actions needed towards a Candidate Recommendation transition.

See minutes online for a more detailed record of the discussions.

Open issues

The group handled some open issues:

• single localizable string: the group agreed that description and accessibilitySummary should allow for several string values (allowing, e.g., multilingual descriptions)
• Presence of id and type should be a SHOULD?: the group agreed that the presence of these terms are RECOMMENDED (although not required
• Bounds of an audiobook: the concept of "bounds" are present in the audiobook spec (normatively) and in the publication manifest spec (non-normatively). Also, although the concept of bounds is useful, it is not clear how to use the concept, there is no specific user behavior attached to it. The decision was to remove it from the audiobooks spec, with the right refeference changes.

The group also discussed actions needed towards a Candidate Recommendation transition.

See minutes online for a more detailed record of the discussions.

PR handling

• There is a new PR for the audiobooks which added some minimal audiobook reading system behavior. The agreement was to merge this PR and possibly discuss it further as an editor's draft
• There is also a new PR for the manifest which moves the WebIDL formalism into an informative annex, and reformulates the processing steps using the upcoming Infra standard. The PR is fairly large and it was agreed to merge this, too, with possibly further discussions.

Draconian handling of conformsTo values

The current editor's draft requires the existence of a conformsTo and it is considered to be a fatal error not to have it in the manifest with a specific profile reference. This was raised as an issue (Issue #101). The rough consensus was that we should not have such a draconian approach, and the editors will come up with a somewhat "milder" proposal (maybe along the lines of a larger proposal in the issue discussion).

Horizontal reviews

• i18n review is closed
• a11y review is almost done, there was only one pending question on synchronized media (whether it can be put on recommendation track).
• PING review answer is pending, although there are no open issues

See minutes online for a more detailed record of the discussions.

Base direction

With the introduction of @direction into JSON-LD 1.1 it has become possible to properly add this i18n feature into the publication manifest. This was done via PR manifest#92. With some minor changes (related on how to communicate the dependency on JSON-LD 1.1) the WG accepted to merge this. With this, the i18n horizontal review has also been closed.

Metadata

There was a discussion (see issue manifest#57) on what exactly the role and usage of metadata is, and how much of that should be visible in the publication manifest. The discussion was around how extensible the current structure is, how easy it is to either incorporate or refer to metadata vocabularies defined elsewhere. No change on the document is required but the WG should keep an eye on the way metadata registries may be handled in the new W3C process coming out in 2020.

Usage of WebIDL

(See also issue manifest#98.) There have been discussion elsewhere on whether WebIDL is the right approach to describe data structures for a spec like manifest. The Web App Manifest spec is moving away from this towards the usage of the "infra standard", that unifies the language used for processing steps and related data structures (although that does not replace the overall view of the structure that WebIDL provides). Infra will be adopted in the document to describe the processing steps; whether to use WebIDL or not remains open for now.

See minutes online for a more detailed record of the discussions.

There was a short report on the TPAC F2F meeting (for a detailed account, see the minuges for the first day and the ones for the second day). At TPAC there were a number of discussions with other groups (DPUB-ARIA, PING, also expert on MathML); there were discussions on testing a CR progressions and plans. On separate discussions there were also advances to solve the base direction issue for texts (a PR is to be expected soon).

Most of the meeting was on planning the details and procedures on the CR testing phases.

At the Fronteers Jam Session, Hidde de Vries (WAI) will talk about how Content Management Systems can make a huge difference for web accessibility.

Abstract

On the modern web, we can design content with the visual interestingness that we've always wanted. We can have beautiful pages and lots of variety. But how can we manage all that content, and maximise accessibility at the same time? In this talk, Hidde will look at how your CMS can improve accessibility — both for content editors and for web users.

See minutes online for a more detailed record of the discussions.

The meeting concentrated on a number of issues that could be either closed or that should be discussed on the F2F meeting next week. In particular, issues 40, 22, 13, and 16 were all closed without further actions, whereas issues 12 (“What is null base URL”), 9 (“Should canonicalization include absolutization”), and 51 (“Values for readingProgression”) were postponed to the F2F meeting.

There was also a short update on the latest editorial draft changes since the last official output. The changes were mainly on the manifest document: removal of the concept for canonical manifests (with the emphasis of a “canonical” representation of the data structures encoded in WebIDL) and the strict separation of the language set for the publication (i.e., the content) and the literal texts in the manifest proper. Depening on external circumstances the new versions may be published before TPAC.

See minutes online for a more detailed record of the discussions.

Horizontal reviews

Issues

The were also some minor LPF issues; the document is essentially ready to go.

On internationalization, a somewhat more complex issue was to separate the language used for the textual content of the manifest from the (main) language of the publication itself. The solution, put forward in an issue comment will be adopted in an upcoming Pull Request.

No meeting next week

See minutes online for a more detailed record of the discussions.

Publication decisions

Manifest structure

The WG discussed some changes on the way manifests are defined in the spec

• The spec makes it clear that the manifest is using a specific "shape" of JSON-LD for the spec (which is also expressed in a JSON Schema) and Reading Systems are not required to have a full JSON-LD implementations
• The previous notions of "authored" and "canonical" manifests disappear; instead, the former "canonical manifest" is simply expressed as a data structure (defined in WebIDL) that is used by a processor. The document will contain a transformation algorithm to that data structure.

Alternative resource

See minutes online for a more detailed record of the discussions.

Web Packaging Workshop report

Dave Cramer was present at the Workshop (organized by IETF) and gave a brief report. The discussion was also around the work currently spearheaded by Google on packaing. The most interesting aspect for this group may be the combination of all resources into a single binary file; a browser may be able to unpack such a file directly. The other aspect ('origin substitution') seems to be more controversial at the moment

Issue Discussions

The group discussed some outstanding issues:

• Creation of rel attributes for extra resources: the resolution was to postpone this. In case there is a real need, possibly try to register them at IANA, but it is not clear whether there is a real need indeed.
• Metadata rendering hits: should they appear in the manifest: these are EPUB properties mostly around FXL. The decision is to keep this open for now, but not reproduce them in the manifest, which is not about rendering anyway.

The Publishing Working Group has made changes to its deliverables schedule and content in recent weeks and would like to provide an update on the changes we have decided to make, and why. A few weeks ago the group resolved to suspend work for now on the Web Publications specification due to a lack of implementer and industry resource availability to complete the work in the chartered timeframe. There was not a clear and immediate business case for the specification. After meetings with the Steering Committee, we have decided to proceed with specifications that have a clear and immediate business need and/or will facilitate future work.

In the coming weeks the PWG will publish a series of notes based on the work we have done so far. The first of these will be our Use Cases and Requirements document, followed by the note version of the Web Publications document, and then later this month the first draft for our Lightweight Packaging Format. An update to the working draft of the Audiobooks Specification that reflects the changes to the structure of our projects is also expected later this month. This update will include some changes in response to feedback we have received.

The final document we intend to publish is a specification for a Publication Manifest. This specification allows us to take the best of the work we have completed thus far and open it up to the digital publishing and web communities. One of the reasons we are bringing this part of the document to the rec track is to facilitate future profiles. Audiobooks will be the first specification to reference the structure of the Publication Manifest, but we expect future profiles to use it as well, like the work of the BDCoMA Community Group and Publishing Community Group. We look forward to seeing future ideas using this specification, and encourage anyone interested to join us or provide feedback via our GitHub repository.

See minutes online for a more detailed record of the discussions.

The group agreed on a schedule for publications for the coming weeks:

• For almost immediate release (depending on administration):
  • A Note version of the Web Publication document
  • The UCR document
• Finalize the next version of the following documents for the 19th of August
  • Publication Manifest (i.e., the manifest part of the current Web Publication Document); this will be a FPWD for a Rec-track document
  • The Audiobooks draft
  • The Lightweight Packaging note-to-be

&The goal is to review those documents on the 19th, publish the document after that (if there is a consensus on the group), then review them at TPAC for a CR afterwards.

See minutes online for a more detailed record of the discussions.

After a brief summer recess the group concentrated on some planning, also following the discussions on which directions to follow for the Working Group.

The planning for the coming period involves:

• Publishing the UCR as a new version of a Working Group Note (as decided on the last meeting before the recess)
• Publishing the current WPUB document as a Working Group Note (which can then be picked up by the Publishing CG for further incubation)
• Create a restricted version of the current WPUB document, tentatively entitled "Web Publication Manifest", which contains the (JSON-LD) vocabulary specification only
• Update the audiobook specification to refer to the Manifest document and also to include audio specific processing. Undecided yet whether this enlarged audiobook document would include the current lightweight packaging, or whether that would remain as its own document for now

The goal is to have these documents "publication ready" by TPAC; a detailed set of milestones should be proposed at the next meeting.