Re: Page break navigation

Thank you for jumping in Matt,

> Adding in the locators is not trivial.

As far as I can tell there is nothing that prevents word processors like
Word, Google Docs, Adobe Acrobat Pro, LibreOffice, etc. from including page
breaks indicators in their export to EPUB, either on by default, or as an
option. This doesn't have to be a manual process. Not only would this be
trivial, it could happen without a content author knowing about it.

Even if no word processor, and no "export from X to EPUB" tool does this
today, I don't think we can assume this will never happen. If any of them
add this, we could see ourselves in a situation where things like
contracts, e-tickets, homework assignments, financial reports, etc. all
have page break locators in them.

> I also wouldn’t say the only benefit here is to EPUB, even if this is
currently where we see it most. There are publications you can read online
that aren’t EPUBs (e.g., through Safari books, Project Gutenberg, etc.).

If that happens it seems like that would be more a happy accident than
anything else. The definition of "page break locator" combines two things -
something has to 1. represent the end of a page when printed, and 2. be
something you can link to. Office formats I know of have both those things,
they just don't happen to be part of the same "element".

Most document formats have page breaks, most of them have bookmarks that
you can link to. This criterion relies on a quirk of EPUB having page
breaks that happens to also function as a bookmark. I don't think that's a
reliable way to decide which document need improved inner-document
navigation.

Kind regards,


On Mon, Jun 27, 2022 at 6:48 PM Matt Garrish <matt.garrish@gmail.com> wrote:

> > Adding in the locators is not trivial.
>
>
>
> Yes, it would help to hear the scenarios that are going to trap
> publishers. When publishers add page breaks that aren’t related to a static
> source, they’re doing that with the intention of helping all users
> coordinate their reading so they add navigation. This SC won’t burden them
> as breaks without navigation defeat the purpose of what they’re trying to
> achieve. As John has pointed out, there are a number of publishers who do
> this already.
>
>
>
> > As discussed previously, CSS break-before/after are not suitable for
> this use-case. They adapt to the content so would result in different page
> numbers between users.
>
>
>
> They also aren’t realistic for EPUB as CSS processing isn’t a requirement
> of the standard. It only is required when there’s a viewport, and not all
> reading systems visually render content, so basing pagination off CSS is a
> non-starter unless there’s another major revision, and that’s unlikely any
> time soon given the disruption major changes make to the publishing
> industry. The other problem with a physical page break mechanism, like CSS,
> is that the markers aren’t meant to create new pages. They solve the
> problem of pagination varying by reading system by flowing with the
> content. A method for synchronizing with static equivalents has to not have
> the potential to break current or future rendering.
>
>
>
> I also wouldn’t say the only benefit here is to EPUB, even if this is
> currently where we see it most. There are publications you can read online
> that aren’t EPUBs (e.g., through Safari books, Project Gutenberg, etc.).
> Not to suggest these sites currently include page breaks, but users should
> have the same access regardless of format. We’re not trying to force the
> sites to provide this functionality, only ensure that it’s available when
> it’s relevant. There are also other projects going on, like some
> experiments DAISY has been doing with books in browsers. There has also
> been interest in using DPUB ARIA roles in Google docs (the request for page
> header and footer roles came from them). So, while identifying pages is not
> as prevalent outside of EPUB, I wouldn’t say the only benefit is ever going
> to be for EPUB.
>
>
>
> Matt
>
>
>


-- 
*Wilco Fiers*
Axe-core & Axe-linter product owner - WCAG 3 Project Manager - Facilitator
ACT Task Force

Received on Tuesday, 28 June 2022 10:32:47 UTC