Meeting minutes
Fallbacks
<Shinya Takami> w3c/
Gautier Chomel: 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"
Gautier Chomel: 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
Gautier Chomel: 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
Brady 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?
Gautier Chomel: 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
Brady 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
Matt Garrish: 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?
Wendy Reid: 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
Gautier Chomel: 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 Gardeur: 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
Gautier Chomel: 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
Wendy Reid: 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 Gardeur: 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
Wendy Reid: our emphasis should remain on well structured content
… but we should discuss alternatives
Ivan Herman: 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 Gardeur: there is implementation within propriety specialized reading systems
… not usually as an interoperable format
… does anyone know if B&N still uses this?
Ivan Herman: does vital source use it?
… if not, we should keep multiple rendition in the past
Susan Neuhaus: what is the next step? Should we make recommendations for creators?
Wendy Reid: This is for the fxl accessibility task force, I don't recommend using html fallbacks because it isn't proven.
George Kerscher: the user who doesn't want that experience may want an alternative
… can we create this?
Brady 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?
Gautier Chomel: 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 Gardeur: 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 Gardeur: 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
Gautier Chomel: does anyone know of a specification on reading mode provided by a browser
Ivan Herman: I haven't seen that
ack: Charles LaPierre
Charles LaPierre: back in the day there was a reader who could show you a scan or a reflowable ocr rendering
Dale Rogers: 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
Shinya Takami: in japan, if we want to mix fxl and reflow, we generate a reflow with some resources fixed.
Susan Neuhaus: so two different discussion. One to go to the fxl group and the other to keep in mind for the future.
Brady Duga: my understanding is that we want to explicitly say what won't work.
<Brady Duga> +1 to Hadrien Gardeur
Hadrien Gardeur: probably, a problem is that many properties are spine based while they would give better benefit in the manifest
HTML Survey data visualization
Susan Neuhaus: 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.
Gautier Chomel: 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
Susan Neuhaus: 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.
Susan Neuhaus: the survey closes in two weeks.
Ivan Herman: 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 Herman: 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 Herman: maybe we should extend the survey period to reach that.
Gautier Chomel: 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
Brady Duga: about getting RS onboard, I can send some messages. I also think we can reach those organizations ACs.
Susan Neuhaus: about if there are blockers, I wonder how we want to display those answers. What we want to share with the community.
Ivan Herman: workflow developers said they would have impossibility to accept HTML
Wendy Reid: we're out of time, let's think more about this for next week.