W3C

Publishing Maintenance Working Group

09 July 2026

Attendees

Present
Avneesh Singh, Dale Rogers, Brady Duga, Gautier Chomel, George Kerscher, Hadrien Gardeur, Daniel Kimberg, Murata Makoto, Masakazu Kitahara, Matt Garrish, Romain Deltour, Shinya Takami, Susan Neuhaus, Toshiaki Koike, Wendy Reid
Regrets
-
Chair
Wendy Reid
Scribe
Gautier Chomel, Wendy Reid

Meeting minutes

<Wendy Reid> date: 2026-07-09

Sync Media and Process Discussion

<Avneesh Singh> Accessible sync media: https://www.w3.org/community/accessible-syncmedia-pub/

Wendy Reid: some of us met to discuss this topic. we suggest to pause rechartering and retake that discussion by q4 when we'll better know what we want to put in this charter.

Wendy Reid: a cg for sync media have been created to get more feedback.

<Avneesh Singh> First meeting of sync media to give idea of discussions: https://w3c-cg.github.io/accessible-syncmedia-pub/minutes/2026-06-26.html#minutes

Wendy Reid: one of open questions is how to collect wide feedback. Maybe a survey like the html one which worked well.

<Murata Makoto> +1

<Murata Makoto> FYI: CBT people appear to provide dynamic TTS (with Karaoke) without special SMIL-like markup.

George Kerscher: we recognise that a lot of techs have evolved since MO was introduced in EPUB. Syncing and generating are part of those. Because of that the use cases have evolved and doing a new use cases analysis is important for the discussion.

Hadrien Gardeur: looking at issues tagged MO, i don't think thta there is one that would break backward compatibility. The problem now is that we ara missing interoperability.

<Murata Makoto> Computer-based testing

Murata Makoto: Daisy people in Japan heavily use MO because TTS is not sufficient. The production process is painfull, we have only one solution and it's a challenge to syncronise.

Avneesh Singh: Hiroshi is representing Daisy Japan in the sync media cg. We have faith in capturing japanese usecases.

Hadrien Gardeur: MO, readaloud, sync, those are different features, sometimes mixed in people mind. It's important to help clear understanding.

Hadrien Gardeur: at EDRLab, we are building Readium speech to ease TTS cross apps. We are planning a speech playground to test and explore how the DOM should be processed and rendered. There are quite a few steps, how to extract semantics, how to represent the information and then what are user powers (settings). A lot of this done at production time makes MO stronger today. By those experiments we hope to make the RS rendering more efficient.

Hadrien Gardeur: still, TTS is in my mind a different discussion than MO.

Avneesh Singh: MO is an authoring format, event if it can rely on TTS generated speech.

Avneesh Singh: we have started to work on user expectations of what a RS generating speech experience. To explore what is expected and procide some guidance.

George Kerscher: at epubtest.org we've been testing readaloud for years. But pretty basic, we don't go in sophisticated things. I agree a lot of work need to be done to improve the readaloud expereince. Also related to position and syncronisation at diferent levels (letters, words, etc.) it's a tiroirs topics, what semantics, what language changing, etc.

<Hadrien Gardeur> Right now, Readium Speech handles voice selection and audio playback: https://readium.org/speech/demo/

Hadrien Gardeur: I started to work on this some years ago, it's now entirely triggered by EDRLab. to help the implementation in our reading tools.

<Hadrien Gardeur> The playground would be a much more exhaustive version of something like this: https://github.com/readium/guided-navigation/tree/main/examples/read-aloud#pagebreaks

<Murata Makoto> How about video containing sign language?

George Kerscher: In the sync media group, we have both use cases in mind, authored and reading system on the fly production.

Wendy Reid: this is a challenge, anything TTS is of interest for our group but we are not the only group impacted, so need a lot of coordination.

Wendy Reid: a lot of spec are out of date, but ownership is not defined

George Kerscher: we don't want to write an ebook specification that would be used by airport anouncements. We can learn from other use cases but our topic is ebooks. and that's already a big topic.

Hadrien Gardeur: webspeech api is accepted responsability of audio WG.

Hadrien Gardeur: I think we should do nothing at this point regarding TTS, contratly to MO where there is a need because it does not work.

<Susan Neuhaus> +1 Hadrien Gardeur

Avneesh Singh: the plan os this accessible sync media cg is to be permanent in time, we think there will be need for long term work. First priority is EPUB 3.5, but there will be future needs. It's our vision.

Understanding EPUB A11y - https://w3c.github.io/epub-specs/epub34/a11y-understand/

Murata Makoto: great work, one concern regarding the title which I think is to wide and does not represent the content. It looks more important than other documents while it is not, it is different. This one focus on relation between wcag and epub, or how to interpret wcag for EPUB. I would like to make sure the title represent exactly the content.

<Susan Neuhaus> s/represnet/represent/

Matt Garrish: we previously had understanding sections in each documents, this one groups all understandings at the same place. It's 50/50 existing texts and new contents. This is not a finale note, it's a draft to get more feedbacks, more people involved.
… it's a step in continuing developing the document.

Wendy Reid: I agree with both concerns. We may add clear mention we are looking for feddback.

<Susan Neuhaus> +1 Wendy Reid putting requests for feedback in draft document

Wendy Reid: understanding is a known word in wcag world.

Murata Makoto: Understanding wcag is not a note or anything, just a webpage. Also it covers everything in wcag.

Shinya Takami: wg and cg can produce notes, that may lead to misunderstandings.

Brady Duga: it's in github, there's been a lot of back and forth. This is a minor step to publish it as a draft. We probably need it published as a draft, title might change and that may come with confusion, but that's part of the process.

Susan Neuhaus: as a pruducer what document should I check, how many documents should I check? I agree we should publish and get feedback.

Gautier Chomel_: Just to make sure, once published as a draft, any issue related to the document will appear in the document as a note, in the case of Murata Makoto's issue it's about the title, would there be a block there or am I misunderstanding?

[discussion of editorial practice]

Wendy Reid: those issue blocks are human authored, not automatised.

Murata Makoto: I suggest two changing, one is a mention about relation between this document and the ones related to metadata. the second change i suggest is a title modification to avoid confusion with wcag understanding of "understanding".

Dale Rogers: i am not sure who the audience of this document is

<Murata Makoto> I don't agree

Matt Garrish: this isn't a technical document, this is a general understanding document, higher level for people not in technics.

<Murata Makoto> Abstract

<Murata Makoto> The Understanding EPUB Accessibility 1.2 guide provides information on how to evaluate the accessible content conformance requirements of EPUB Accessibility 1.2 [epub-a11y-12] against reflowable EPUB publications.

<Susan Neuhaus> +1 Wendy Reid about the number and discoverability of documents

Gautier Chomel_: I would like to see Murata Makoto's proposals, having issues to discuss, we should review the proposals

George Kerscher: I need this ressource on my activities, as soon as i get it, i will use it.

Wendy Reid: we need a map of documents anyway. We have a lot.

<Hadrien Gardeur> +1 we need an index at least for all of our documents

Avneesh Singh: I've seen such an index years ago, but it's not very easy to use either.

<Dale RogersRogers> +1 for an index. This is one I know. https://www.w3.org/groups/wg/pm/publications/

<Matt Garrish> https://www.w3.org/TR/?filter-tr-name=&tags%5B%5D=dpub

Minutes manually created (not a transcript), formatted by scribe.perl version 248 (Mon Oct 27 20:04:16 2025 UTC).