Does Prince support aria attributes like aria-flowto to change the reading order of a document? I want to keep how the elements are located visually, but have the screen reader read the document in a different order.

Edited 11 Mar 2025 by ayu1

Prince does not use aria-flowto, as PDF does not appear to support multiple alternate reading orders.

Interestingly, specifying the PDF/UA-1 output profile does produce a PDF document with an explicit reading order, at least according to the accessibility checker I'm using; however, Prince does not seem to expose any mechanism for modifying the reading order it produces.

As far as I know a PDF can only include one reading order (while aria-flowto can potentially express multiple choices, like a choose your own adventure book!) and providing a mechanism to reorder the document would require some care as it might be easy to produce a broken or incoherent structure tree.

I'll defer to your expertise regarding how difficult it would be to implement. I will observe that this is something I also have a use case for, though: I use Prince to lay out technical manuals, where the optimal default reading order for screen reader accessibility is often somewhat complex. I'd be willing to accept the risk of accidentally breaking the document tree in order to have finer control over the reading order.

(If it's a matter of an author-specified reading order potentially conflicting with the document tree hierarchy, just being able to manipulate the reading order of sibling elements within the same parent would suffice for most of the scenarios I have in mind.)

Edited 13 Mar 2025 by David J Prokopetz

Do you have an example of when that would be necessary? For example swapping the reading order of sibling elements without swapping the document order / display order.

Hi,

The 'order' property is intended to change the visual order, while leaving the logical order (and reading order) intact, so this could be an alternative solution. Prince supports the property for flex and grid, but an author-specified visual order can conflict with the page ordering if the container fragments, in which case the logical/reading order will be forced to match the visual order more closely. This in turn interacts with the sizing algorithms for flex and grid, which in turn can affect fragmentation, and thus we have a circularity.

So the problem is complex, and we currently simplify it by constraining the reading order quite a bit more than necessary. (In other words, the order property changes the visual order as specified, but it also changes the logical/reading order in cases where it doesn't need to.)

There are a number of ways we can try to improve this situation, but we really need use cases. So please send them in if you have them

Mark

I'm afraid I don't have an example I'm at liberty to post at my fingertips, but broadly speaking, the one we've bumped into most frequently is when working with a source document which makes use of absolutely positioned ::before and ::after pseudoelements to do tricks with generated content.

In the reading order produced by Prince, it always seems to go ::before first, then any other children of the same parent, then ::after, which is reasonable in most cases. However, owing to the absolute positioning, the pseudoelements may both visually precede, or both visually follow, the element's other children, resulting in a tagged reading order which is inconsistent with the accompanying visual layout.

Thanks, that's useful to know. I agree absolute positioning is a good example of when a feature like this would be necessary