Consider a mechanism such as "play order" for Fixed Layout publications

[GeorgeKerscher]

In the DAISY 3 Standard, ANSI/NISO Z39.86, we had to resolve a problem with the proper sequence of content. I believe there is a similar problem with fixed layout publications.

The idea would be to establish a structure that identifies the correct sequence to present the information. A few could be chosen that presents an alternative to something in the fixed layout that is an equivalent representation of that portion of the fixed layout version. It should then be easy to toggle from the fixed layout view to the alternative version and maintain the position in both views.

From the DAISY 3 Standard we have:

8.4.3 playOrder Attribute (This section is normative.) The playOrder attribute is required on each pageTarget, navTarget and navPoint. It provides a means to collate all pageTargets, navTargets, and navPoints into a single ordered sequence that reflects their order in the normal playback sequence of the book as presented in the spine and SMIL file(s). playOrder is a positive integer; the first playOrder value in a document shall be 1. When the content elements of any pageTargets, navTargets, or navPoints reference the same SMIL time container, they must have the same playOrder value. playOrder must increase by one for each unique SMIL time container referenced by any pageTarget, navTarget or navPoint.## Issue on the EPUB 3.3 Recommendation

[gregoriopellegrino]

Interesting solution to explore.

I think in the context of Fixed Layouts done with HTML and CSS, perhaps DOM order and CSS (z-index) can suffice to fix the visual presentation.

The challenge is when the reading order goes from one page to the one next to it and then back to the previous page... In this case defining a read order above the DOM order would make sense.

I think we should find a solution that works natively with browser rendering engines, otherwise I see complicated integration with assistive technologies and reading applications.

[mattgarrish]

I think we should find a solution that works natively with browser rendering engines

The closest we have is aria-flowto, but it's limited to elements within the current document. We might want to work with that group to allow cross-document references, or to define something like an aria-flowacross for this case.

The web doesn't have a concept of spreads, so reading across two visible viewports is not a use case I expect they'd have considered.

[iherman]

This was discussed during the pmwg meeting on 25 September 2025.

View the transcript

Issue #2664 - w3c/epub-specs#2664

wendreid: we don't have playorder officially from documents since we got rid of the NCX
… playorder is inferred from the spine

duga: I assumed this was to put play order inside elements within the document?

wendreid: are they talking about reading order within the HTML itself, that comes from the DOM

mgarrish: without George here we aren't sure

gautierchomel: maybe we can tag it with fixed layout
… in my experience in training, we have never had a problem with at fixed layout reading order
… it is doable for now
… let's tag it for fxl and discuss it in the fxl a11y context

wendyreid: yes, let's do that

gautierchomel: if you have two html files, and the title is part on one page, and part on the other, you may need to do this
… but it can be achieved with code now

mgarrish: this sounds like rendition mapping
… he wants to move from fxl to something else
… which is a huge issue we've never solved
… and he wants a new mechanism for moving around within content

wendyreid: I'll leave this alone until we can talk to George
… are there any more things to discuss

gautierchomel: some of the issue topics can be pushed into discussion

wendyreid: we didn't consider that, we didn't have that option in Github before
… we have used issues for everything. Now that we do have discussions as an option
… we could explore this
… we could set up guidelines about when to set up a discussion and when to open an issue

AvneeshSingh: multiple channels of communication can be trouble
… we already have internal reading list, public reading list

SueNeu: What is the functional difference between a discussion and an issue in GH that makes discussions a better idea?

wendyreid: discussions are designed to be a bit more like talking to people
… the accessibility group uses them, responses can be threaded
… one of the problems can be hard to follow comments when they overlap
… it makes for a better flow of discussions

mgarrish: the threaded replies don't always work the way they are intended
… we would want some guidance for people about when to open discussions and how to respond
… if you don't have a specific problem you want addressed in the spec it makes sense to set up a discussion even if the discussion threading isn't perfect

wendyreid: I'll do some research on GH about discussions
… this might be more geared toward opensource projects
… there is some merit giving people space to ask a question that isn't a direct issue

---