Meeting minutes
Making substantial changes to EPUB
wendyreid: first topic is about substantial changes to epub - we have been maintaining the spec since we published it last year - 3.3 was mainly a maintenance update
wendyreid: we are looking at one change around webtoons but there are other things like using html syntax, annotations, updates to make the format more modern and adaptable
wendyreid: our charter expires next june so we were going to have to have this discussion anyway
wendyreid: our current charter locks us into maintenance - we can correct errors, typos, small tweaks to existing features, but cannot add new features
wendyreid: we need to talk about the future of epub - we can look beyond epub 3
<wendyreid> w3c/
duga: I see that there are at least two broad categories of changes we can do - reimagine things as epub 4, and then little things like webtoons where we want to add metadata that doesn't break backwards compatibility
duga: we need a way to do the smaller things without necessarily doing the big
<gpellegrino> +1 to Brady
<tzviya8> +1 to duga
duga: need a way to get two implementations and get a feature in the spec quickly
ivan: a little bit the same as what Brady said - we need to separate what we're thinking of doing - epub 4 is a big step that may not be worth the trouble
… there are some things that we can dream up that sound good - for every item we should have a clear statement showing this is what the industry needs
… industry is also not uniform - reading systems and publishers needs can differ, but it should still influence what we do
<gpellegrino> +1 to Ìvan
rickj: the concept of an epub 4 is scary because of adoption time, but we need to do some things
… we don't want to break backwards compatibility but I have no way to know what differs between versions of epub 3 we do produce
<liisamk> +1 to knowing what each thing is
wendyreid: I agree with Brady and think in the short term we look at necessary changes to 3.3 and then in the longer term consider an epub 4
… epub 4 is going to be a five year project and that's not even including adoption into the real world
… I don't want to get too fixed into only working on 3 or only moving to 4
duga: it would be interesting to see if there's an easier way to do maintenance - to add features in addition to the minor changes
… maybe instead of profiles we can flag new features that may not work
ivan: administratively speaking class 4 changes are not allowed and we have to recharter for that
tzviya8: historically we haven't had good success with profiles - but we do have ways of calling out content like mathml in documents
… in terms of business v technical needs we can't do one without the other
… we had tdm (text and data mining) community group note and it's had a lot of uptake but as a note it didn't go through testing - as a result it didn't go through the W3C AC and get feedback that could have been useful
<tzviya8> +1 to rickj
<gpellegrino> EDUPUB!
rickj: education market has dramatically changed in the last 20 years - we put learning materials into the system now only books - is that part of the conversation
liisamk: we've always wanted to look at multiple marketplaces - are people willing to come have that conversation
… last 20 years of epub has worked in the marketplace but has been dumbed down to work for the lowest common denominator
… we need the nicer features but also have the fallbacks work
wendyreid: if we were to think up design principles for epub adaptability and flexibility would need to be top
… the same format is for a text-only novel as for a textbook as for a manga
… we want them all to be well produced and accessible
George: I want to echo what Rick said about education - epub content is being integrated into an LMS but also with testing and quizzes so moving beyond epub sphere
… we're not testing reading systems that are integrated into LMS because they are not fully epub
… it's also influencing what is happening in libraries
… we also have accessibility and the evolving legal frameworks and the problems with fixed layouts that need addressing
ivan: I would like to understand what it means technically for epub to be into the educational space
… what are the possible changes need to better fit the educational space
dlazin: I want to go back the question about what we're chartering as - bug fix or to develop new features
… one of the things I see as someone who hasn't built a reading system is this group has a lot of history in background but the next generation won't have this info
… there is a limited opportunity to do an epub 4 right with that knowledge
… ebooks is a growing space and looking 50 years in the future I can't believe we'll still be on xhtml
<tzviya8> +1 to dlazin
dlazin: I'm in favour of chartering for an epub 4 and doing this now
LaurentLM: everything comes back to business needs - only one I see is to replace every textbook by reflowable for all students
… they want to have quizzes and pass information to a server - they are using pseudo-epub with html inside, not xhtml
… as long as most reading systems don't accept post requests from content I don't think this will go anywhere
wendyreid: we all agree that we want to continue to evolve epub - is there anyone who has concerns or objections to us rechartering on developing epub 4 or adding new features
ivan: the fact that we have put ourselves in the position of not allowing class 4 changes I don't think we can recharter by just taking that clause out
… if we recharter we need to list very specific goals that we hope to achieve and create a new working group
… we need to make sure we don't make this mistake again of not allowing additional changes
… it's never too early to start the rechartering process
is it correct that what is required is to think again what the attitude is? javascript is grudgingly accepted, for example. Scripting is understandably insecure but they are also important - we need to rethink how we formulate scripting support
… are there other things beyong scripting that education will need?
LaurentLM: if we move to html syntax this is a major evolution as many reading systems won't handle non-xml formats
… if we put epub 4 in a charter it will make the publishing industry anxious
gpellegrino: for me it's okay to go for a new charter if we split the track between big and small changes - we need to improve semantics for education
<CharlesL> +1 to two tracks for new charter/ 1=EPUB New, 2=Small new features / fixes
ikkwong: why did we stop at 3.3?
rickj: 3.1 had breaking changes
ivan: fear of rejection if we left things open to change
AvneeshSingh: worried we should not be scaring the industry - we should keep backwards compatibility even if we add incremental features
… the education field is continuously evolving - we should ensure the changes are incubated in the community group
<Hadrien> +1 for incubating in CG before moving to a WG
rickj: from our perspective, there are three integration points: LMSes, courseware (homework system), and textbooks - the latter is epub
… every system has a reader so we're down to the lowest common denominator - need a way to announce what is supported
<Makoto3> I will go to bed and come back in the last session to discuss the PAS submission of 3.3, RS 3.3, and A11Y 1.1.
duga: I didn't propose two tracks but two types of changes we need - two tracks we might have a tough time staffing and maintaining
… it feels like the CG is not getting to ideas we pass to them
<tzviya8> +1 to duga
<ivan> +1 to bduga (alas!)
duga: if we don't get the process right we're going to end up with big efforts that don't go anywhere, like edupub, etc.
wendyreid: I think the two streams idea came from me but it's more like a roadmap in chartering - one stream is things we want to incubate
… I've been doing some internal research on html and it's not a big deal to us in terms of how our reading system is constructed or renders content
<tzviya8> +1 to wendyreid
wendyreid: we're always going to support whatever is thrown at us - we still support epub 2
<Zakim> tzviya, you wanted to comment on lessons from 3.2
wendyreid: we aren't going to drop support for xhtml because we add support for html
<dlazin> +1 to wendyreid
tzviya8: we need to look at what went wrong with 3.1
… very few business people were involved in the decisions - the workflow ended up being problematic
… we have not had an effective chair of the CG for some time so we need to look at how everything gets supported
wendyreid: action item: what should a roadmap for the future look like - not focus on the current charter but what we want to do
<wendyreid> w3c/
wendyreid: we need the use cases and needs for education
ivan: I will look into the sweetest and shortest way to recharter - to see if we unbind ourselves from the current lock on features
Scrolled content / webtoons
<wendyreid> w3c/
<shiestyle> My slides: https://
shiestyle webtoons born in Korea, market increasing in Japan
using rendition-flow:scrolled-continuous metadata today
shiestyle: : major systems like Apple support this
shiestyle: (earlier) webtoons born in Korea, market increasing in Japan
shiestyle: (earlier) using rendition-flow:scrolled-continuous metadata today
shiestyle: mechanisms for webtoons are not defined yet
shiestyle: propose new metadata w3c/
shiestyle: Hadrien's proposal in https://
shiestyle: Want to continue to support the Apple (rendition-flow) metadata as well as new metadata
shiestyle: because otherwise old webtoons won't work; we need backwards compatibility
shiestyle: passing to Hadrien to explain his proposal
Hadrien: rendition-flow is a little misguided
Hadrien: it suggests that you can have fine-grained control in how an epub flows
Hadrien: But you can't. The user decides. That's what epub is about.
Hadrien: Thus rendition-flow is not a well-used feature of epub.
Hadrien: Might want to consider dropping layouts (fixed layout?) in the future, but let's not talk about that now.
Hadrien: A webtoon doesn't behave like a fixed layout.
Hadrien: Today fixed layout means that everything is contained in the viewport. That's not what you want for a webtoon.
Hadrien: For a webtoon, you want only the full width in the viewport, not the height.
Hadrien: There is no such thing as a page in webtoons.
Hadrien: Consequently I have a hard time with the idea that a webtoon is fixed layout.
Hadrien: Misusing a property that is already problematic is not a good idea.
Hadrien: My proposal instead is a new property for rendition:layout, which would be `scrolled`.
Hadrien: Would fit to the width of the viewport, with a continuous scroll.
Hadrien: A few other optional things:
Hadrien: break-scroll-before: current webtoons only allow single episodes
Hadrien: this new property would allow multi-episode epubs (like buying a graphic novel or an entire season/series)
Hadrien: There are other scrolled comics (bottom-to-top, left-to-right) which are experimental, but thus you should be able to specify the scroll direction
Hadrien: that would be rendition:scroll-direction
Hadrien: proposal available on Gist, https://
wendyreid: a third proposal!!
wendyreid: or maybe fourth, who knows, not me
wendyreid: agree with a lot of Hadrien's proposal
wendyreid: I see a very big issue with adding a third value to rendition:layout; it will break reading systems
wendyreid: so we keep rendition:flow but add an update to dir (direction) or add scroll-direction
wendyreid: also add spine direction and other episode metadata
duga: I did a proof-of-concept implementation of webtoons
duga: thus I see why the Apple/Amazon version is not a level-3 change
duga: it's a huge change. It's a brand-new type of fixed layout, which means we have to update a zillion sections in the spec.
duga: this is not a bugfix.
duga: fixed layout flowing epubs do not exist in the spec, but do exist in reality
duga: for webtoons, the whole epub is fixed layout
duga: so the benefit of using the existing property is gone
<LaurentLM> +1 to brady: this would not be a level 3 change
duga: so to Hadrien's point, it's a bad idea to reuse this flag just because it already exists.
duga: as wendyreid says, if you give Hadrien's epub to Google Play Books etc, it will break
<LaurentLM> +100 to brady
duga: and that is GOOD because it will break at ingestion and prevent users from spending $5 on a thing that the RS can't render
liisamk: what's happening in this space from a business perspective is exactly what happened with children's picture books initially
liisamk: there wasn't a way to do them in epub
liisamk: Apple found a workaround, people started making/selling them, and then we doubled back to support them officially
liisamk: what's probably happening today is people are making two files, one for one partner and one for another
liisamk: or not selling it at all
liisamk: whether we like it or not, this is already happening, and expanding across the world quite quickly
liisamk: process question: whether you are going straight from webtoons to digital product, or introducing a print product in the middle
liisamk: some publishers are buying webtoons, breaking them up to put them on paper pages, and digital adaptation happens after that
liisamk: they want the ebook to mirror what they had on the print side
liisamk: right now that workflow is making them into regular fixed layout
liisamk: (liisamk is not saying this is a good thing, just reality)
liisamk: there is a business need to have fixed pages sometimes and flowing the rest of the time
shiestyle: I also oppose adding a third value to rendition:layout
shiestyle: this would break existing webtoons
shiestyle: if we add new metadata for webtoons, scroll-direction is enough
wendyreid: the complication is real and important
wendyreid: but the requirement for backwards compatibility is a real bind
wendyreid: today, if I were to download a file with this new value, the worst that would happen is I would get a paginated book
wendyreid: that's not ideal, but we still want it to work even if it's not the bestest
<George> I would like to know more about Lisa's statement that higher education is using fixed layout. In the titltes I see, that is not the case.
wendyreid: it's great if e.g. Google breaks at ingestion, but some users are downloading epubs directly, opening them in Thorium, and will be upset if they break at that point.
wendyreid: We should better explore this mixed-experience content in future versions of epub
Hadrien: Mixing up a lotta different things here.
Hadrien: when I hear that the content is redesigned to be paginated, and we want to allow the user to choose between paginated and scrolled, that's quite different between what we're talking about in the past with webtoons.
Hadrien: Big difference between a user preference for how you consume fixed layout vs content that will be broken if you don't force the behavior for webtoons.
Hadrien: fixed layout today is already good enough for what liisamk described.
Hadrien: Japan is not the biggest market today for webtoons.
Hadrien: in all the biggest markets, webtoons are just images in a .zip file.
Hadrien: the majority of the business around this is not on EPUB today (outside of Japan)
duga: like liisamk said, this is fixed layout repeating itself
duga: but we didn't just take Apple's implementation; we made it fit into the spec
duga: today, there are two ways of supporting fixed layout, Apple's way and the official way
duga: that is annoying, but we don't need to take Apple's way of doing it (specifically). We should design the best thing for the spec and if we have two varying implementations again, so be it.
Dale: The web world has graceful degradatation
Dale: Edit: The web world has graceful degradation
Dale: I'm wondering if RSes see content they don't understand, do they ignore or do they just crash?
wendyreid: Most reading systems do the best they can to render.
wendyreid: The graceful degradation principle carries over ... with some limits.
wendyreid: For example, epubcheck has some errors that will prevent bad content rather than RSes trying to render it.
liisamk: Most reading systems do not render the epub exactly as delivered.
liisamk: RSes have ingestion processes (usually) that change things -- modifying CSS, etc.
liisamk: There's a big black box of people not knowing what happens or why.
liisamk: I would like to see the publisher/author to be able to indicate a *preference* for how a book should be rendered, but give the reader control as an override.
liisamk: Sometimes the content is optimized in a way that is not the reader's preference.
Hadrien: Not sure it's true that *most* RSes transform input, but the biggest ones do.
Hadrien: The vast majority of (small) RSes don't change the file.
Hadrien: Flow and spread are both examples of misused features.
Hadrien: So RSes try to have sane defaults and give options back to readers.
Hadrien: These properties where we're made mistakes in the spec are almost useless, because they're not well supported.
Hadrien: Another way of consuming content is one full viewport at a time. That's not quite paginated, but it can be useful for accessibility.
duga: The way liisamk describes scrolled-continuous is exactly how it was intended, but it's so hard to use.
duga: If it was my product, I would not bother implementing the default scrolled-continuous; it's a lot of work for a weird user experience that people will turn off.
liisamk: Many RSes take defaults that a reader sets and apply it to all content.
liisamk: This isn't really a standards question, but we should consider whether preferences should apply to all books equally.
liisamk: Readers don't really understand how much the RS decisions affect their reading experience.
<duga> +1 liisamk
Hadrien: At Readium we have preferences per publication, global preferences, and a mix: initialized with global settings with per-publication overrides.
Hadrien: Some users need that (e.g. for accessibility)
Hadrien: You don't want to have to fix typography settings on every single book you open.
wendyreid: This is cool but we are off-topic.
wendyreid: We have been talking about webtoons in circles for a while.
wendyreid: We don't need to make a decision today, but we should get towards one.
<CharlesL> +1 that was my point of view Dyslexic users will want a specific font which helps them read more efficiently same for low vision users with a specific font size etc.
wendyreid: How do we get to a path that makes sense in EPUB 3.X, and how do we fix this better in an ideal future?
Dale: Question is who has control — the original designer or the reader?
Dale: Some questions are design issues, some are accessibility issues
Dale: I would like to advocate for the perspective of the designer who is creating the book.
LaurentLM: The Apple proposal is not a level-3 change.
LaurentLM: In the previous discussion we agreed we should recharter.
LaurentLM: Let's do something clean in EPUB 3.4.
LaurentLM: That is, we don't need a level-3 change, and that's OK, because we're going to recharter anyway.
<rickj> +1 to Laurent's comment to recharter
duga: Agree; let's recharter and do something good and new.
Hadrien: Maybe in Japan, with specialized RS, the Apple way will continue to exist.
Hadrien: Maybe those RSes will have aliases from one metadata property to another.
Hadrien: It's not that big of an issue. It's acceptable to have two ways of specifying the metadata.
Hadrien: e.g. if you see flow:continuous-scroll plus layout:fixed, you would treat that like layout:scrolled.
<LaurentLM> rendition:layout = pre-paginated + rendition:flow = scrolled-continuous => rendition:layout = scrolled in EPUB 3.4
ivan: let me restate Hadrien
ivan: we define a new (thorough) approach
ivan: then we also document the practice by Apple/Amazon Japan, to indicate that that solution is still around and must be understood (aliased) in the context of our new properties
duga: we didn't do that for Apple's fixed layout
ivan: the market was smaller then!
<dlazin> +1 to ivan
<shiestyle> +1 to ivan
ivan: it doesn't cost us a penny to document the aliases
ivan: there are two aspects of where we go from here: the chartering is on me
ivan: but the modification to the epub spec can continue in parallel
ivan: modifying the Reading System spec is more complex than modifying the file spec
davidhall: (complex thought about whether we need to recharter to handle Apple's current implementation, which dlazin didn't capture well)
BREAK TIME! Re-convene in 26 minutes
Locators and Annotations
wendyreid: Reminder. we are no longer thinking about the charter.
… what are the problems we are trying to solve
wendyreid: things we worked on in the past. work by Readium, etc.
… location and wayfinding in EPUB and annotations is important and education use cases.
… there are problems with the current implementations. we do some things well every platform has implemented it differently
ivan: I was part of the annotations work. important browsers implementation. main motivation annotatins should be exchangable.
… data format for storage on an annotation server.
… details with JSON storage is beside the point.
… it has failed usage with web browsers. one implementation which is Hypothesis but never opened up their servers which is private.
… is there a market to exchange data among Reading Systems.
… big question is exchange of data.
… make sure there is a business case first. but would love to see this work done.
… clear market for Webtoons there is a market need. but for annotations I am skeptical.
Hadrien: important keep in mind are higher level features.
… need to look at what has changed. new building blocks on the web.
… scroll to text fragment. implemented in Chrome
… there is a way now to reference text on the web without fragment IDs.
… we can not get accesses to that low level. highlight interface CSS highlight
https://
Hadrien: we have this now available on the web.
https://
Hadrien: use cases - Readium we have toolkits where 100's of developers are using. Organizations need this feature need on desktop mobile, web.
… if we build that into toolkits that are widely used. bloggers could use this with interoperability.
<dlazin> +1 to liisamk ALREADY
liisamk: Focus on use case of reader taking their notes from one platform to another you will get pushback. wall gardens
… every reader want to keep their notes without fear of loosing them.
… author selling annotations is an interesting proposition. reading groups sharing annotations.
<Hadrien> +1 for archiving as well, this goes beyond publication updates, a lot of ebooks are borrowed from libraries where users lose access to the publication after 21/28 days
liisamk: allow users to mark things up, highlighting / need. books get updated minor things tech fixes, author adding new content. many versions over their lifetime.
… many updating from EPUB2-3 and adding accessibility. keep their annotations.
<Zakim> ivan, you wanted to react to rickj
rickj: business case for Education with Hypothesis, professors assigning their books. When tying a grade to reading highlighting making notes engagement increased.
… there are engagement reporting systems and this needs to be interoperable with this.
wendyreid: user interest in this is gaining. iPad / Apple pencil. writing tools, social media how they note take and process information. huge online and engagement with technology. Readwise
… we want interoperability but would be great if they worked with other platforms.
rickj: we need to interoperate with Hypothesis
ivan: since Hypothesis is a closed system.. right.
<LaurentLM> a closed system like Hypothesis cannot be considered a standard...
Dan: clear business case page numbers how we use books. We didn't reinvent the book we reinvented the scroll.
<LaurentLM> hypothesis may be considered a monopoly by default
Dan: sharing page numbers when folks are on different reading systems or if a new version comes out which changes the page numbers. we need standardized page numbers.
<tzviya8> +1 to dlazin
Dan: we know there is a very strong use case for page numbers.
… important, we don't want to have an algorithmic page numbers we need publisher defined page numbers. great to get a consistent display of page numbers.
<Zakim> duga, you wanted to talk about data export
duga: we want to do these annotation things.. what about simple import / export?
… we don't have to do the centralized server. Patrons could get their annotations.
… wall gardens - maybe could shame them into adoption.
… Microsoft would have loved to have if you could "bring your annotations with you".
George: reading is a very personal experience. keep forever their annotations and bookmarks, share with children / grandchildren. save these annotations. Wish I had this 20 years ago.
Dale: retired as a professor using an LMS from an educators POV. if a student sent in a grade appeal, if I had to document that, I would go into the LMS and determin how engage that student was in the class. I would have to make sure the LMS could give a report and it could tell me if the student read a particular book / page etc. I am not sure if I could find out a the page level in the EPUB, I heard the argument for the education use case, not sure an educator would want to do.
liisamk: move towards more a11y content, a lot are including page numbers and backlists remediation does include this. vast majority of Ebooks have real page #'s and where they were sourced from in the metadata.
… there are times for better reading experience you may re-order content and what should the page #'s do if the order changes. but keeping the mirror with the print book even if it is out of order in the digital book.
LaurentLM: Readium near prototype shared our spec.
… use cases are in the spec, archiving is in the spec.
… audio books and web publications. first use case is import / exporting annotations or sets.
<tzviya8> Readium document readium/
LaurentLM: EPUB is the only format we are thinking for annotations.
… we are not planning on pushing to a server, there is Hypothesis for that.
… please comment in Github. in a few months we will have a prototype to demo.
ivan: we would have to justify why we want to do this work.. AC would be asking so this is good.
… important to remember the standard we would adapt and what Readium has done. not the UX experience that is outside of this. export/import or on a server. we must keep in mind to define a format that can be exchange.
… other part that is important terminology "selector" / locator generalization of page numbering. how to hook an annotation in the content.
… usage of selectors go beyond annotations.
… question: annotations standard for EPUB the standard does not modify the EPUB 3.3 itself.
… the Readium maybe storing an annotation within an EPUB.
<fantasai> Saw someone drop a link to ::target-text earlier; here's a few related items:
<fantasai> https://
<fantasai> https://
Hadrien: Archiving - ownership is less common, we are given temp access. different reading env. some you may loose access to it. you may get subscription platforms but bringing that into another platform when I am no longer a student etc. archival is very important and should be the core of how we think about this.
… selector we choose will be important for archival. less brittle (CFI will break if you update anything)
<George> +1 to Hadrien archive and personal bookmarks and annotations
wendyreid: I am a student now and this is very frustrating.
… locators: this is essential. most books are not coming in page numbers. we can not self publishers, they are using services. massive part of the EPUB market.
… we need to be mindful of that, as the maintainer of the standard.
<liisamk> I can show you all of the ways they are different...
wendyreid: lot of interest in text fragments, perhaps supporting multiple
duga: CFI's are hard to make and define. there are copy quota and you may try to annotate every work and steal it. that is a concern.
<Hadrien> copy quota are already dead with the ability to extract arbitrary text from any screen/screenshot/photo on mobile
<Hadrien> I know at least 5 different ways built-into the platform to circumvent copy quota on Android for example
George: EBSCO for their patrons is absolutely essential. if they don't have page numbers they must us an algorithm so that they distribute with page numbers. we need a way to standardize this or all citations will be a major problem. great if we could standardize this.
ivan: rechartering - annotations becomes a separate document along side the others. we have to do a rechartering with a new deliverable. We have no choice.
… does the WG agrees that annotation should be a separate document and not just tacked onto EPUB spec?
<Hadrien> +1 for a separate document
Dale: I like the idea of it being a separate document. finished a 3 year program some had print, digital, reading EPUBs on laptops, PDA's etc. getting to a particular page was just about impossible. We would say go to first chapter 3rd paragraph 2nd sentence is what we had to revert to.
… if the DOM could take care of tracking things vs the Reading System.
… I am an independent author as well, so I would just update changes when I need to make a change then the DOM may be updated as a result.
mgarrish: the authoring / rendering (this is not a core authoring / rendering) but more of a satellite spec.
rickj: Matt just answered my question. I agree.
<George> annotations, locators, and get citation in scope.
wendyreid: we would have to decide if this is a NOTE vs a Rec Track doc.
Phillip: are you thinking of creating a new metadata vocab?
ivan: No, we may need to extend the annotation web spec.
Phillip: charter ends next year, and you don't have to wait. the charter doesn't care if its a separate document or not just depends on if it is in scope or not.
fantasai: don't try to put technologies specs in.
wendyreid: we also need testin NOTEs. They belong on REC track, for IPR reasons and Processg included.
CSSWG Update
fantasai: invite if you all need css support for improved layout etc. please see us. During EPUP3.0 development we had a great collaboration with EPUB folks that really improved internationalization for both CSS and EPUB; so if you need more CSS abilities please come talk to us.
<fantasai> https://
<fantasai> https://
fantasai: working on spacing of text line to line, sizing text in more precise ways. inline layout spec.
… adding this box can be sized based on certain size metrics.
… top of some text and an adjacent images etc. so this will help with that.
<fantasai> https://
<fantasai> https://
fantasai: related features line heights are calculated.
… we would love to have more feedback from publishers.
<fantasai> https://
duga: you don't need to be part of the CSS WG to comment?
fantasai: correct all welcome to comment.
wendyreid: we will break for an hour.
LUNCH TIME - be back in an hour
Legislation and Accessibility
wendyreid: For this session, talking about upcoming worldwide legistlation
… particularly EU A11y act
… particularly what is remaining?
… Also some changes to US Title 2
… What impacts does that have to publishing?
… And if anyone knows anything about other laws
"international people"
wendyreid: Start with EAA - what is left?
gpellegrino: I have a brief overview of the last year for EAA
… EAA requires a11y for different types of products and services
… Coming in June 2025, so about 9 months out
… Includes ebooks, reading apps, toolchains, etc
… I am not a lawyer, please refer to one if you need to!
… All ecommerce has to be accessible, as well as banks and other services
… Europe is using the latest version of web accessibility (2.0?)
… We have shown to the European commision that we are already in compliance with the laws, via our accessibility specs
… There is a note that has a mapping for a11y, and udated epub a11y to put it in line with the European requirements
… Specifically, epub a11y references WCAG 2.0 level A
… WCAG 2.0 Level A is not sufficient, as is clear from the mapping
… There was some issues with DRM which are being discussed
… finally EPUB fixed layout is the last problem.
… The user must be allowed to change all text properties (line height, font, etc)
… Some types of publications may not allow these types of format changes (e.g. comics)
… But that is why we think exploring a11y in fixed layout is very important
… Last TPAC we delayed ISO transition until after EAA
… as such we ask that we delay ISO until after June 2025
ivan: Where are we on discussions with the European Commission? Is the danger of being sidelined still there?
christina: We are on a good track, there is a new meeting this week, they are willing to start the delegate access for this.
… So we will have an answer soon
wendyreid: What is the issue with ISO?
… delay isn't a problem, but why do we need to delay?
christina: Because the relationship between international and European standard is tricky, so we want to leave the choice to the commission right now
… They need to make a petition to the EU standards body, and if the is an ISO standard that is confusing
… So it will take time.
George: If there is an ISO standard it must be harmonized, but W3C standards are easier
CharlesL: We also published a note on the exceptions, so those need to be harmonized.
<rickj> Link to the 'note on exceptions' that Charles mentioned?
ivan: Another practical Q - first a quick summary of this mornings session
… Are we under any obligation to extend a11y to annotations? Is that a problem in the EU?
christina: Thinking aloud - I never thought about it in this light. If they are part of a reading solution, then I think they may be included
… maybe leave as is and go back later
<gpellegrino> +1 to Avneesh
AvneeshSingh: I don't think annotations matter. The mapping we did has no need for annotations. So I think we are ok
gpellegrino: +1
… We don't have in the requirements for the EAA specific requirements for annotations so we are ok
… But the Reading System must be in accessible
ivan: How does this relate to the exception for fixed layout?
wendyreid: Which of the documents will they recommend?
… If it is just a11y 1.1 then that is fine, but if it is the epub docs then do we have to worry about changes we will make
christina: No, I think we will be ok with epub changes
duga: Ivan, you said the exception was for fixed layout, it's for comic books, right?
… some comics reflow, and fixed layout is not a thing in the spec
cristina: The act requires accessibility, but within the limits of the publication, not compelled to make all comics accessible if its not possible
<gpellegrino> Specific features of special volumes like comics, children’s books and art books should be considered in the light of all applicable accessibility requirements.
gpellegrino: Adding some quotes from the act
… about fixed layout, it is an interesting challenge to find an accessible version of fixed layout
Hadrien: Coming back to comics, it seems like an unknown quantity
… This will act will become local law, with regulators, so it is still unclear exactly what will happen with these publications
… but fixed layout as it is today is not enough to meet the requirements
… The biggest is the ability to change text property
… maybe we can extract text and maintain the order of words
… But comics are different, since the text is often in the image
… could provide a script of the page, but that has limitations
… But even that is hard since reading progression may jump around pages
… we may need a fragment based approach instead of resouce based, similar to SMIL
… Would require some extensions or a new format
mgarrish: Back to annotations, I think it will depend how they are expressed
… e.g. if they are HTML, then that covers it
… But it may depend on where they came from (e.g. for sale by publisher vs reading group sharing)
davidhall: Some comments on comics
… the statement about what is possible, it might be possible to extract and read text from images, so will regulators require that if it is possible?
<davidhall> https://
davidhall: and then there is region based nav, has that come up
wendyreid: We never talk about fixed layout with region based nav coming uo
… example of a good idea that never really made it
… The fixed layout group discussed complex content a lot
<ikkwong> +1 to wendyreid
wendyreid: Sometimes knowing where the text is is just as important as knowing what it says
… we still don't know what the best solution is
… we do want to incubate on it
Hadrien: I think region based is interesting, but not enough
… it works across fragments
… but can't map back to content of the speech bubble
… when it comes to what can be done on device, it's a good point
… sometimes we can detect panels, etc
… I have made an accessible comic that shows some of these things
liisamk: I would note that there is one large implementation of region based nav
… comixology uses it
duga: The other not-exactly region-based nav is google books' bubble detection
… good for highlighting parts of the page, but it is lacking parts like text
… what can be done on the device? But also a worrying question about what the EU can ask
<davidhall> +1 duga
duga: if apple intelligence can read out the page and describe it, will it be an expectation, if it's not a native capability of the reading sytem, you're in trouble
<gpellegrino> #notALayer
christina: It is a tricky answer, but the commision is the first time we are making it possible for everyone to do the same thing
… if you look at the list of possible examples, that will evolve. It just isn't possible to cover everything
… so all we can is monitor what is going on
… and then go back to the commission
… we can only get to a stable place and then adapt as time goes on
Dale: I just published a comic as an ebook, and wanted to figure out how to make it as accessible as possible
… so I got into an argument with ChatGPT with the best way to present this
… I ended up taking the image, sent it to chat gpt, and said "please describe it". I got back a very good response
… I was able to use a lot of that text in the alt text for the image, enough for the reader to follow along
… what I want to know is, is that enough?
<Zakim> gpellegrino, you wanted to ask about ADA
gpellegrino: Maybe we should move to ADA Title 2
… the approach to EAA with the mapping seems like a good approach
<tzviya8> +1 to ADA time
<George> I think that is a good start!!!
gpellegrino: it seems to have good results
… any thoughts on that?
wendyreid: as I understand the goal is to use WCAG 2.1 level AA
… so we are pretty good already
… Currently this is education, but it may be to Title 3 which includes business
<George> A bill has been introduced for Title 3.
rickj: The discussions I have had is the Title 2 change is very similar to EAA
rickj: main difference is the stick associated with Title 2
tzviya8: Education hits a lot, eg a journal in a school is educational
… So they may have trouble (or maybe not)
… Just a new segment exposed to ADA
CharlesL: Some districts aren't sure if Title 2 impacts them
… something to do with the size of the district
… So it is 2 vs 3 years
… It's not the district count, but rather the area, so it is confusing
… But budgets happen in Sept., so a lot of districts are going to have trouble
George: At least we have clarity on the backlist, which is explicitly included in Title 2
rickj: While there may be small districts with an extra year, the suppliers will all be impacted earlier
… since they sell to all districts
wendyreid: Is there anything we need to do to support anyone?
rickj: We are the publishing working group, what about pdf?
… it feels like we should help people with that
I have to go pick up a kiddo, so goodbye for a while! See you in a couple weeks, I think?
liisamk: If we go down the PDF road we have to look at their a11y
… having looked at it there is a lot of weird stuff
… alt text isn't consistent, etc
tzviya8: I don't know how far down the PDF hole we can go
… But ARIA WG is looking at working on this
AvneeshSingh: Touching on pdf - we have been discussing the metadata requirement in the cg
… A lot comes from onix, but we should bring in some pdf people to discuss
… so we will learn more from the pdf peope
… We should discuss what adopting some wcag versions would have internationally (in the cg)
wendyreid: we have some incubation work and some discussion work - anything else we need to know about?
ivan: I was wondering if the doc we made for the EAA would help for Title 2 as well?
wendyreid: To rephrase, the EAA and epub a11y was done for the commission
wendyreid: so they understood how we fit in their framework
… I don't think this is the same for title 2
rickj: I think you are right - title 2 has been around forever, it is just newly interpreted
George: When a publisher with an epub that hits wcag AA they will be in great shape (assumign they are telling the truth)
CharlesL: Benetech has been a leader in certifying people
… So we are really far along with 3rd party certs for title 2
George: K-12 is not as solid as higher ed
… still a lot of work there
… and I am really concerned with reading systems
… we don't see it as much with publisher reading systems embedded in the LMSes
… we have also not been able to connect with libraries
… so very big open question
Dale: so if we run it through ACE ...
George: No
… If you use ACE with Smart and the KB, then that is the right thing
… so GCA and LIA and MATT (err.... Matt?) [something something - maybe acronyms or names]
CharlesL: Things about SMART and WCAG and other things and it grabs it and puts it in the places
Audiobooks Accessibility, TTS
wendyreid: 2 parts to this session. May not need to talk about the second
… audiobook spec has a11y section, was not extensive
… recent talk in the industry around audiobook a11y…we have no place to send them
… some research going on (Canada)…do we want to take up the task of writing an equivalent audiobook spec like EPUB for a11y
… audiobooks may get pulled into legislative scope
Hadrien: DAISY items missing from current audiobook spec
… navigation missing for atomic levels, jump ahead/back, etc.
… ability to sync text/audio in EPUB, but missing that when primary resource is audio
… if this is important, we need the ability to make a fragment correspond to an audio section
… new things for group to discuss... if we want to
matt: touched on this a bit in the EPUB spec…possible opening there to address it
… this could be a new standard (not harmonized with existing) and may need a wider group to be involved
Wendy: DAISY mentioned…hard part is audiobook spec was targeted at commercial market, not the a11y market
… may need new tools (or change how copyright works!) for production of audio content (rights issues/legal issues)
… similar problem to FXL … cannot solve all a11y issues…can solve many of the issues, however
… TOC, image descriptions, including all parts of the book (footnotes, index, ...)…
… DAISY is the gold standard, can we find something commercially viable that we can do
AvneeshSingh: audio books seen as a downgrade from the DAISY standard
… EPUB a11y work started in 2014, standard from IDPF, in 3.0 work need for something to be done was recognized
… needed a structure to support the industry. ACE/SMART/Knowledge base came into being… adoption happened
… on audiobook side still needs to gain some traction … Thorium implementing some solution, similar to spec,
… do we need to change the spec to increase adoption?
… where to put our resources?
George: The audiobooks are accessible, not usable (as a list of MP3 files)… downgrade from DAISY
… could add TOC, etc.… not sure what the appetite of the industry is to do the work
… most DAISY books have full book, but not text
… with DAISY the primary media is the audio, as opposed to media overlays where audio is supplemental to primary text
CharlesL: without TOC for audiobooks, issues with WCAG in general. Can't skip.
… with text transcription also need sign language for deaf
… big rabbit hole
Hadrien: need to separate interchange format from end user format
… EPUB tries to do both… current spec 'feels like' both
… Readium work on end user part, seen adoption in library space, good traction
… Audiobook is a resource based format. DAISY is a fragment based format
… trying to bridge that gap in Readium toolkits
… getting to a point to have fragment based approach along side of resource based approach
… in comics: page based format along side of panel by panel
… we need to do the same thing with audio
Dale: thinks of audiobook like MP3 file, no interactive elements
… on Youtube can get audio with links to time signatures, takes me to a chapter, buttons with CC information.
… is this what people want to interact with audio content?
wendyreid: Avvneesh asked a good question: Do we have the bandwidth?
… however, this is a question being asked by the publishing industry
… issues with using DAISY, want another solution/do better
… on the display side, we want to do better, better affordances
… RS can do this, but need some information from the file for interchange/delivery
… we could make more usable than they currently are. No consistency or guidance for publishers who want to do better
<Zakim> tzviya, you wanted to stop aiming for perfection
tzviya8: If we strive too hard for perfection, we will never get there
… there is demand for a solution here (real demand from publishers)
… we have to figure out the priorities, and how to implement
Ivan: the audiobook standard we published has not been a success
…question: Because it is not accessible? or other reasons?
… if a11y, then if we add features... hope of success?
… if not... then, is this a standard that has not made is. Put in more time/energy?
matt: can we make a mapping of what improvements we can do?
George: having worked with audiobook publishers… they are audio people… don't understand markup
… would be happy to embrace a standard
… would be happy with an equivalent of an opf file
… automate ingestion
… pubs would need a tool to help produce this? [tooling questions]
liisamk: part of our issues with the success of this spec was timing
… serious problem as the audiobook world was expanding to get information to various parts
… spec came as other people had solved some of this stuff
… i.e. send a package of tracks, with an excel doc, that gave you the information needed
… tooling was figured out for specific differences in needs
… we need to help them solve a problem they have, but awareness of the problem may not be big enough
Brady: it may be why it failed, but it still failed. Spend more time working on it?
… does the EAA apply? No. Can we force that? :-)
dale: audio books purchased to listen where they cannot read
… Alexa example of audio 'interaction' rather than a spec
… does this align with the same needs here for interactive elements?
Text to Speech
wendyreid: a requirement of EAA
… no clarity on what is required
… do we need [not] a standard, but best practices?
George: the quality of TTS engines are surpassing existing.
… if you have the text, you can use these engines to generate the audiobook
… features need to be identified. epubtest.org has test book for read aloud. basis for RS implementation/testing
… more could be done/added to test book, but don't see support for it in current implementations
… reading alt-text, reading math, TTS speed controls, all needed
liisamk: To George's point, many leave out img alt text (or even mention an image), many have no speed control, no structural info, etc
… It would be good to add some notes to this so the information will be properly used
<CharlesL> +1 to Liisa's comments
ivan: I don't understand the question. TTS exists outside of this group
… so it not in scope to work on TTS
… these are all real problems, but they are relevant to TTS engines, not us
… what are we supposed to do?
wendyreid: We are on the front lines, what we do impacts everyone who uses TTS
Hadrien: it's a complex topic
… there are a few things that push this forward
… So two things pushing this forward, both EAA and also audiobook generation
… nothing about read aloud is well documented today
… e.g. want text and structure, but not sure if we should use html structure, or epub stuff, etc
… For instance, what should I say about chapters
… for some implementations we are limited by web tech
… which can be a bit of a mess
Hadrien: We have SSML etc that can't really work with the speech generation (e.g. SSML says use a "male" voice, but that isn't exposed)
janina: APA has been trying to crack this nut for a while
… CSS meeting - invitation to join to discuss this
… problem at root is no 1 engine for reliable output the same across platforms
… trying to get on top of that
… lots has gone on, details available to forward if interested
wendyreid: work happening in SSML, CSS speech (link above to spoken-html)
… not trying to tackle those problem - but rather what gets read in the first place
… is all potential content (lists, image desc, etc.) being read from the EPUB?
… different implementations in different reading systems. No standards for users
… no best practice to give guidance
<Zakim> tzviya, you wanted to ask if a11y issues are EPUB or DOM
tzviya8: are we reinventing the wheel? Does ARIA doe this?
… all the information is there. AT typically offers options to the reader (toggle on/off, etc)
… is this just HTML and ARIA?
CharlesL: we have guidelines/recommendations to give to publishers for the correct markup such that RS can take advantage of TTS better
… worked with Apple to get DPUB-ARIA roles prioritized
… what is important/ not important and not spoken
… guidelines for RS to implement read-aloud
shiestyle: Japanese text has ruby
<Makoto1> See https://
Makoto1: draft of technical note about ruby (link following)
(link above)
wendyreid: not all our responsibility. Impacts EPUB, but we need to reach out to APA, ARIA, others to work on together
Hadrien: massive topic to cover it all. Work on voice selection. Extracting semantic text into SSML next
… talking to specialized library org's is a good approach
… wants to establish baseline of what we can do
<Makoto1> ISO!
ISO
<Makoto1> In my understanding, last year, this group decided to submit EPUB 3.3, EPUB RS 3.3, and EPUB Accessibility 1.1 to ISO/IEC through the PAS process. However, because W3C ran into procedural issues with the PAS submission of WCAG 2.2, our PAS submission was also delayed.
<Makoto1> Fortunately, Daniel Montalvo Charameli from the W3C team has completed the consultation with the ISO Central Secretariat regarding the PAS submission of WCAG 2.2. A few comments from ISO/CS have already been addressed, so we can likely apply the same approach for our PAS submission.
wendyreid: for ISO, pushing again since the EAA deadline need to pass before we can do anything so we do not disrupt the process
… WCAG has a harmonized standard. EPUB does not.
George: Europe has harmonized standard for WCAG
… when we submit WCAG to ISO, they already have the harmonized standard in EAA
… if we submit the EPUB A11y spec to ISO, it would trigger the need in the EU for a harmonized standard
… would mean years of work
… current plan to adopt EPUB a11y 1.1 as a standard is in process. Don't want to trigger the need for a harmonized standard
… once EAA is enacted, then submit to ISO, any work in that period the EAA spec would be in effect, rather than delayed
Makoto1: problem in Korea as they must use ISO, and are locked to use version 3.0.1
wendyreid: we keep this in mind and get ready to submit in summer
ivan: we know the document we have today, in the format we have today, cannot go to ISO directly. We need several months of work to convert them
… if things in the EU move as expected, may start the conversion early next year
wendyreid: I will talk to the WCAG team to find out what they had to do to do the ISO conversaion so we can know what we need to do
Ivan: talking about getting 3.1 to ISO, talking today about a new 3.x version (webtoons, annotations, ...)
wendyreid: WCAG had a previous version, we may have access to same means with ISO for a shorter path