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.