Re: [EXT] RE: Page break navigation

Thanks, Matt!
Unless I’m misunderstanding it does sound like this may need adjustments to software that don’t yet exist today.
Would it make sense to make this a Level AA — given that technology isn’t quite ready to support it at this time? I trust that reflection went into selecting this as Level A, would someone please advise on the reasoning?

From: Matt Garrish <matt.garrish@gmail.com>
Date: Tuesday, June 28, 2022 at 7:20 AM
To: 'Wilco Fiers' <wilco.fiers@deque.com>
Cc: 'Alastair Campbell' <acampbell@nomensa.com>, 'WCAG list' <w3c-wai-gl@w3.org>
Subject: [EXT] RE: Page break navigation
Hi Wilco,

> 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.

Absolutely, I understand the concern you would have with these, but I’m probably more sceptical that this is something they would ever do by default. inDesign still doesn’t have an export feature for pagination and that’s with a user base that would benefit from it. Having hard-coded page breaks for basic word processing documents would be unnecessary, so I’d expect this would always be an export feature you’d turn on. That or the program would handle adding the accessibility needed. DAISY has a Word to EPUB export that handles both pagination and adding the page list, for example, but it requires the user to hard code the page breaks.

That’s generally how the requirement has come to be worded the way that it is, in requiring the navigation only when the markers are explicitly present.

> I don't think that's a reliable way to decide which document need improved inner-document navigation.

The success criterion is more broadly scoped than what EPUB has in its accessibility specification, but I don’t expect it’s possible for WCAG to try and scope the requirement the same way as EPUB, either. EPUB’s requirement for including pagination focuses on providing page navigation where the publisher can reasonably expect their content will be used in mixed print-digital environments. In an ecosystem where content is sold, that’s easier to determine than it ever would be for web at large.

From a publishing perspective, though, the SC seems like a fair compromise in that it captures a significant part of what we need. While I don’t discount it could capture unwanted content, if exporting page breaks becomes widely used in the future I’d also expect there would be equal interest in being able to access the pages through AT, which would remove the need for authors to do anything special for the web.

Matt

From: Wilco Fiers <wilco.fiers@deque.com>
Sent: June 28, 2022 7:32 AM
To: Matt Garrish <matt.garrish@gmail.com>
Cc: Alastair Campbell <acampbell@nomensa.com>; WCAG list <w3c-wai-gl@w3.org>
Subject: 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<mailto: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
[cid:BCBD7D4B-677E-4B95-AE3F-60005DBD9EE4]