Meeting minutes
Fallbacks
<shiestyle> w3c/
gautierchomel: The question from FL a11y guidance doc (a hybrid doc), on reviewing it the RS part has some stuff about supporting fallbacks. It says "in cases where it is supplied, RS should support"
gautierchomel: but we are missing a section on what can be done or not with them. The only guidance is in the main spec, which does not say what you cannot do
… there was some work done on auto-reflow on FL, with intent to use HTML fallback on an HTMLresource
… We realized it wasn't the right way, but if that was attempted then it means the spec isn't clear enough
… For example, can I have an html fallback for svg? Spec doesn't say no
… to me this is a question to address in the FL doc, since it is specific to reflow documents in FL docs
gautierchomel: but group decided not to address it there and do it here, though I disagree with that and think it should be in the FL doc
duga: why do you say html fallbacks of html aren't the right way to do it?
…did it break reading systems and not work in practice?
gautierchomel: the reading system already accepts fixed layout. I want you to use a fall back, we were asked to add a button to select the fall back. We can't do that.
… in thorium we will offer a fall back view, but we won't be allowed to switch between them
duga: I don't know what is right for your reader, when we created the fall back spec we decided it was legal to have a same type fallback ie html with an html fallback
… we didn't specify how a reading system can determine which file is the fall back
… I don't think we should limit the fallback and say you can't fall back to the same filetype
mgarrish: I agree that we could fall back to a different file type. This is an interesting case, because fallbacks weren't made with fixed layout in mind
… how do we indicate which html is fixed layout and which is reflowable?
wendyreid: the other thing making this complicated is that this use case is maybe out of step with the intention of fallbacks.
… "the reading system can't render the original" so it has a file it can render
… this particular usage is not that the reading system can't render the original, but that we want to give the user choices
… there should be a different mechanism for that. There could be other alternative cases
gautierchomel: we should not address the reading system giving a choice to the reader, that is up to the reading system
… some reading systems don't display anything when they encounter a fixed layout
… still we should know what we should and shouldn't do when an rs cannot display an fxl
… and does this go in the fxl document or the main document
Hadrien: I have seen things like this before,
… Barnes and Noble wanted to keep the print like experience, but also offer a reflowable
… but there isn't a one to one mapping between the fxl and the reflowable assets
… B&N chose multiple renditions with a document that could map an area in fxl to the reflowable
… Hachette creates multiple rendition epubs without mapping
… fallback will not work well because of the mapping issue
… we probably need something more like an alternate
… there is a similar proposal in the comics task force
… it would be easier for some publishers to have an easy way to map the html to a resource
gautierchomel: let's separate the discussion about fallbacks and alternate renderings
… still the issue about what should I do in an fxl file that can't be rendered
wendyreid: the challenge is that an fxl file can't be shown or renders badly
… this is like the audio only readers, the problem isn't fixed layout, but that the file doesn't follow semantic html
… so the guidance we have in place would still solve the issue
Hadrien: we are working on Thorium mobile, we already support the ability to listen to an fxl
… with a well structured fxl you can have a decent voice experience. But this isn't always the case
… we will try to process and find sentences and groups of words
… it won't work if there is no text or text is out of order
wendyreid: our emphasis should remain on well structured content
… but we should discuss alternatives
ivan: we took multiple rendition out of 3.3 because there was no implementation for this
… is that still true, or should we keep in the past
Hadrien: there is implementation within propriety specialized reading systems
… not usually as an interoperable format
… does anyone know if B&N still uses this?
ivan: does vital source use it?
… if not, we should keep multiple rendition in the past
sueneu: what is the next step? Should we make recommendations for creators?
wendyreid: This is for the fxl accessibility task force, I don't recommend using html fallbacks because it isn't proven.
George: the user who doesn't want that experience may want an alternative
… can we create this?
duga: we don't have to solve the world's problems
… it sounds like the issue is we want to use fall backs
… we tried this but it doesn't work.
… for fixed layout books, we might have multiple documents point to a single html
… do we simply need to say that fall backs don't work in this case?
gautierchomel: one problem at a time. We just need to put a note in the fixl document
… maybe in fxl specs
… in the future we should let content creators know how to restyle this html
… in the future multiple rendition might come back
Hadrien: what we want to do in Thorium is the style selection you can do in a browser
… and use no original styling
… I am doubtful that people will be excited about this and use it again
Hadrien: what we want to do in thorium web is the equivalent of the reading mode in the browser, so there's no way to style this form a content creator perspective. Multiple rendition have not been used, we should not want to try again.
… I would be happy to point people to what already exists
gautierchomel: does anyone know of a specification on reading mode provided by a browser
ivan: I haven't seen that
ack: CharlesL
CharlesL: back in the day there was a reader who could show you a scan or a reflowable ocr rendering
DaleRogers: I created an epub, fxl, a short comic, with a reflowable introduction and backmatter that was reflowable
… according to the spec I can do this, it worked in Apple Books
… Amazon wouldn't take it. I chatted with someone who looked at his epub
… they suggested uploading it as a comic book
… and not allow the front matter and back matter to be reflowable
… their creator tool requires loading in PDFS that can't be made accessible
… there are some platforms on which this will be accessible and some where it isn't
… even though the spec says I should be able to do this
… it takes me aback that I can't always use features listed in the spec
shiestyle: in japan, if we want to mix fxl and reflow, we generate a reflow with some resources fixed.
sueneu: so two different discussion. One to go to the fxl group and the other to keep in mind for the future.
duga: my understanding is that we want to explicitly say what won't work.
<duga> +1 to Hadrien
Hadrien: probably, a problem is that many properties are spine based while they would give better benefit in the manifest
HTML Survey data visualization
sueneu: we are reaching the end of the survey. I started to play with collected data to see how we can visualise it. I wonder if a binary pro vs con numbers would be of use.
gautierchomel: There is a grey zone between pro and con, I am afraid giving those numbers gives a false feeling
… It is more graduated than the numbers might suggest
sueneu: showing data visualization on my screen. I broke pro and con by role. I agree there is a lot of grey area. We could have multiple people scoring reactions. The pain will fall at different point depending on roles.
sueneu: the survey closes in two weeks.
ivan: yes, a lot of grey area, but we have to do a binary choice. I think we should make a report to adress those grey areas regardless of the final decision.
ivan: another problem, is that representation is not sufficiently distributed. We miss more reading system responses. That may invalidate the whole exercise. I hope we get more answers from apple, google, kobo.
ivan: maybe we should extend the survey period to reach that.
gautierchomel: We might want to extend, we are also preparing a response and will have it soon
… back to binary choice, I would like to see if there are blockers
… are there people for whom html will totally break things
… even if 90% say yes, if 10% have big blockers then we should not say yes
duga: about getting RS onboard, I can send some messages. I also think we can reach those organizations ACs.
sueneu: about if there are blockers, I wonder how we want to display those answers. What we want to share with the community.
ivan: workflow developers said they would have impossibility to accept HTML
wendyreid: we're out of time, let's think more about this for next week.