Meeting minutes
<wendyreid> date: 2023-01-08
<wendyreid> https://
Wendy: today we'll talk about the document Gautier put together for reading systems...
this should be useful for reading systems, but should also be useful for content creators to see...
what goes into rendering their book
Gautier: I've been working with my colleagues at EDRlab to make the draft...
We consider everything in this draft is doable...
it is important that any guidance we provide remains doable, so I invite anyone who is maintianing a reading system to let me know if...
anything presents problems.
Guatier: I am proposing 3 sections, one is what should be shown to reader...
second is what should be done by the reading system...
I want to provide more technical guidance that we should discuss what we can do in this document...
giving more data to the large reading systems...
some of what is here applies to all kinds of epubs...
the third part is some recommendations about contents rendered through tts...
We realized since we use tts in fxl...
we think it is very doable in fixed layout...
any attempt to display textural view of the layout may end up with a strange reading experience...
but I think we can do that..
when we inform the reader...
Hadrien: I gave examples of companies doing something similar, including one with a panel view that extracts text...
some of these are more interactive epubs that us js to transform them into pseudo reflowable epubs...
If text is in a logical order, you may be able to produce a reflowable view...
you may have to recreate a good experience from complex html...
although a fixed layout is not displayable as reflowable, a reading system could display it as such if it is properly formatted...
This is more interesting than building a mixed publication that is fxl and reflowable...
this is much more doable
Wendy: We do want to experiment with content that is switchable. It might be fun to build it...
Even if we are mocking it up in a browser...
If you use semantic html and not too fancy svg, it is doable...
We could prove to publishers it is possible and convince reading systems to do it...
Gautier- Did you mean CRM protection or accessiblility protection
Gautier: yes, maybe it is not in the right place in the document
Wendy: we generally avoid mentions of DRM and it is more a content creator concernf
Hadrien: yes but it is an inportant part of the EU specification
Wendy: I understand that as long as your format supports AT, and the book can be taken out of the ecosystem with out damaging it...
Wendy: We are looking at exiting Adobe ADE protection, it looks like Adobe is sunsetting ACS
Wendy: I think the features described are completely reasonable
Gautier: my main concept is about the interactivity between the reading system...
I don't want to have so much guidance on fxl that we ignore other files
Hadrien: Other than the ultimate textural render all of this applies...
there is a lack of guidlines about how you can send the data for screen readers...
Wendy: There's very little guidance about what reading systems should do with html components...
there is not much consistency with how AT interacts with them...
we've all had to reinvent the wheel on running heads and page breaks, etc.
gPellegrino: maybe in the Daisy documentation there is documentation about this...
<wendyreid> https://
Hadrien: I think page break markers isn't a good example, they are a bit all over the place...
Wendy: we could write something, I don't want to get too prescriptive and tell implementers how to implement...
It might be strange to have page number specs in the fxl document...
Hadrien: I see this as an issue, for example, non linear resources...
they are not displayed consistently. The risk is when we don't define anything...
the implementation is all over the place...
setting some expections would make for a better reading experience though we don't want to be too prescriptive
Wendy: maybe the best way to do it through the tts experience...
Hadrien: there's alot that goes into presenting tts...
including changing languages, pauses...
Gautierchomel: maybe we can start with the tts and come back to the other groups and get their point of view...
maybe it isn't our job to provide this guidance...
we should get more input from different groups about implementing tts...
I couldn't find much about this, even for browsers...
Wendy: Adding a description of what should be in the tts...
it shouldn't be just in the fxl document...
maybe there should be a text to speech test case...
gpellegrino: there was a document made my [marisa] on synchronized media...
there were some interesting thing that pertain to this work on tts.
Hadrien: I think this is different, with synchronized media someone has broken things down for you...
with tts you need to do this, you need to get into the DOM...
most browsers have built-in ICU capability to break down to the sentance or word level
Hadrien: the kind of textural view we're talking about is similar to reader mode in browsers...
alot of what you need to build proper reader mode would work for building tts...
gautierchomel: I have not found browser reading mode implementation...
we often are asked to escape semantic html limits for asides...
asides should be escaped but nothing else...
what readers are looking for is different levels of assited technology in reading systems...
maybe we should offer some guidance
gpelligrino: the company [Okette] for saving pages for offline shared their code as open source...
this could be a starting off point...
Wendy: Text to speech is on the cusp of assistive technology, some people consider it assistive text and some don't...
there's little guidance for cases like asides, footnotes, captions...
I wonder if mapping to what screen readers do would be a good place to start...
we may be getting ahead of ourselves for now...
and we could give recommendations and not be too descriptive...
Hadrien: the EU is forcing our hand in this matter...
In PDF they have used two arguments about making them accessible...
zoom capability and making reflowable...
we could use these arguments too, and we have the advantage...
Epub is based on html. With semantic html and some guidance we can do better with what we have...
Wendy: this is a rabbit hole we probably have to go down...
I'm concerned with the scope of this document...
similar to the recommendations around aria roles...
for now, let me get this copy edited and into the document...
I can tie this to specific WCAG criteria as well...
structurally it is good
Wendy: the only missing section is the synchronized media section...
SueNeu will work with pgellegrino to make a pull request
Hadrien: If the metadata isn't correct, even a properly formatted document could cause problems...
we found in schools that when people were disappointed with tts, they didn't see it as a document issue...
whatever you do, you compromise something...
we should have the conversation about whether some features should be informed with the metadata...
Wendy: yes, we want good experiences, but in the next couple of years, we may have lots of content that may be accessible...
but doesn't have the metadata...
so I wouldn't want to punish content that doesn't have the metadata...
ingestion platforms have a role, since we parce the content...
"this book could have accessiblity metadata"
Hadrien: the EU guidelines say you should present the metadata without changes...
if you read the roles in the ebook chain, we may not be able to make optimal reading experiences...
does the publisher point to the intake platform?...
This risks people not doing anything...
Wendy: maybe its too easy to blame the publisher...
you want the end user experience to be good but not step on any toes...
at the end of the day we want what is best for the user but getting there is challenging
Wendy: I will get this ready and we will discuss it next week