Fallback definition and authoring guidance is missing

[gautierchomel]

Section

No response

Describe the problem

The Fixed layout accessibility guidance for reading systems section has a dedicated 5.3.9Support fallbacks subsection but the Fallback concept is only mentioned once in the authoring part of the document and once in the technique document.

For content creators, that can be confusing as a whole possible authoring part is not explained or addressed.

Describe the fix or new feature you propose

Add a section between 2 and 3 to describe fallback and how it can be implemented or not in a fixed layout context.

Alternatively, a subsection in one of sections 1 or 2 could help.

[iherman]

This was discussed during the pmwg meeting on 28 August 2025.

View the transcript

Fallbacks

<shiestyle> w3c/epub-specs#2773

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

---