W3C

– DRAFT –
FXL Accessibility TF

12 August 2025

Attendees

Present
CharlesL, CircularKen, Dale_Rogers, elguerrero, gautierchomel, gpellegrino, Hadrien, SimonM, wendyreid
Regrets
-
Chair
wendyreid
Scribe
elguerrero

Meeting minutes

<wendyreid> date: 2025-08-12

Issue #2773 w3c/epub-specs#2773

Gautier: There's a whole subsection about fallback in Section 5 539. If I search for fallbacks, I get 7 references while I have only one short reference in section 263.

Gautier: We should start with this document and provide more detailed information.

Gautier: Add a subsection maybe so it's contextualised.

wendyreid: Primary document just says "See main spec" for details on fallbacks but we don't go into detail about how fallbacks work or what to fall back on to.

Gautier: I think we should have a discussion on this, if someone has a clear view on how a fallback should and should not be used.

<wendyreid> https://www.w3.org/TR/epub-33/#sec-manifest-fallbacks

gpellegrino: Isn't fallback deprecated from the main spec or it was not supported?

wendyreid: We had a discussion when we did 3-3 about status of fallbacks because it was unknown — didn't know the support for fallbacks so thought it was an at-risk feature.

gpellegrino: There is a note to specify fallbacks for images and content.

<wendyreid> https://w3c.github.io/epub-tests/results#sec-consolidated-manifest-fallbacks-results

wendyreid: We thought it was at-risk, still discouraged it, but weren't sure if it was supported and when we did the testing, it was medium-supported.

wendyreid: There are passing, failing, and not applicable tests so support for manifest fallbacks is mixed.

wendyreid: We should be specific in the techniques doc that you should test them in their target reading systems.

wendyreid: Raises question if we should advise against fallbacks or you can but that's a high risk.

gautierchomel: I've seen epubs with fallback on HTML resources, and the fallback was pointing to a TXT file — if you were trying to read the epub in Daisy, it would be empty content and no sync.

gautierchomel: Maybe the problem is more general and should be addressed to the main group.

gautierchomel: I know the humaware devices find a fallback after spine XHTML resource, instead of XHTML

Hadrien: Content aggregators don't care about XHTML in digital comics.

Hadrien: Recommendation is to point to XHTML and teh spin but points to the image in a fallback, instead of having to inspect the content.

Hadrien: This is already used by Japanese publishers and is considered the leas harmful option.

gautierchomel: I am wondering if this fallback question should be addressed or become a subject of a community group meeting.

wendyreid: We need to get more input, fallbacks are a universal feature not just in fixed layout.

wendyreid: There's a fallback reflow document but I don't think it will work regardless of structure of HTML.

wendyreid: Valid question for the group at large

Hadrien: Fixed layout and reflow thing, seen in the past by Barnes and Noble done not through the spine. France doesn't do it through the spine either. They use multiple renditions which is its own set of problems.

Hadrien: Technically you could have a fallback to another XHTML and could indicate using a spine override.

Hadrien: I don't think you'll have a 1:1 equivalent of reflow.

Hadrien: You're not forced to paginate in reflow.

gautierchomel: The way forward may be so that there is a mention that this is an open issue and should not be used to provide the reflow content alternatively to fix layout contents.

wendyreid: We should push the discussion out.

wendyreid: If you use the spine overrides, spine item is actually reflow and have a fallback on it, it attempts to first reflow the original XHTML resource which is not the same result as the fallback resource.

wendyreid: Fallbacks are meant for when reading systems cannot render spine item.

gautierchomel: Maybe the section or subsection we need could be more general about providing alternative content or resources.

gautierchomel: Maybe have an informative section saying if you want to add an alternative rendition, these are experimental and should not use the fallback.

gautierchomel: Fallback mechanism is not accepted by vendors.

wendyreid: Vendors don't support fallbacks the way they should, but fallbacks is for when original content cannot render, if a reading system was capable, it would never go to the fallback.

Hadrien: I don't think fallback nor multiple renditions are a good idea.

Hadrien: I think they only work for very specialised use cases.

Hadrien: Mostly useful for processing rather than rendering.

Hadrien: Average reading system doesn't know anything about multiple rendition.

wendyreid: Feeds back to our discussion about alternative stylesheets. A mechanism where you could have a fixed layout style sheet and your reflow stylesheet for your content and finding a way to signal to the reading system that both version are available

wendyreid: Currently not supported.

wendyreid: We have a patchwork of support for features that may or may not help with this problem and is not consistent. It's a walled garden.

wendyreid: We can discuss in the WG to get people's thoughts.

gautierchomel: I can open the issue and discuss in community group and add a note what place would be best.

wendyreid: I can add a note in the primary document.

gautierchomel: There are 2 open issues: Section 3 for package metadata and Section 4 for accessibility metadata — I think that flexibility metadata should be a subsection of Section 3.

gautierchomel: Merge Section 4 into Section 3.

<CharlesL> +1 to that :)

Hadrien: I mentioned that we are in the process of implementing a reading/reader mode in toolkits for fixed layout to give you a heads up. We're beginning with extracting content from the DOM, and conversation is around how to traverse DOM and how to extract info from it. What do we do with images in fixed layout? Separate reflowable view from

fixed layout should it contain images or include the description of images?

Hadrien: Will be done in web reader project, and a toolkit called Readium Web and a reading application called ? web?

<CharlesL> playground.readium.org (I believe)

gautierchomel: For alternative rendering methods, you don't need to do fallback, if you produce a WCAG-compliant layout then we can reflow it. In Section 5.4 has a placeholder for this reflow rendering.

gautierchomel: Have a draft for the reflow label rendering and will be updated before the end of the year possibly.

wendyreid: If you make a good fixed layout doc, you have a good TTS compliant document

Toolkit is Readium Web and app is Thorium Web

gautierchomel: I have an issue with issues because some of them in the epub spec repo and the publishing CG there is an issue for fixed layout in the fixed layout and reflow label. We should make a choice of the place of this document.

wendyreid: At the very least make copies of epub specs, or move them where the document lives.

wendyreid: There's a lot of overlap and anyone can comment in the epub specs repo.

gautierchomel: Transferring issues from CG to the epub spec Github?

wendyreid: Should have permissions to do that.

wendyreid: Will get that PR together on main document and will send to you for approval.

wendyreid: See you in two weeks. :)

Minutes manually created (not a transcript), formatted by scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).

Diagnostics

Succeeded: s/human/humaware/

Succeeded: s/web devices/devices/

Succeeded: s/? web/Readium Web/

Maybe present: Gautier

All speakers: Gautier, gautierchomel, gpellegrino, Hadrien, wendyreid

Active on IRC: CharlesL, CircularKen, Dale_Rogers, elguerrero, gautierchomel, gpellegrino, Hadrien, SimonM, wendyreid