RE: [EXT] RE: Page break navigation

Jennifer,

While I can't speak for Matt, I don't believe that Matt was saying software cannot support it.  I believe he was indicating that software today like MS Word is not inserting programmatic page break locators and if they did it would likely not be by default.  This means the SC would not apply to those documents because there were no programmatic locators  - not that it couldn't be met.

Jonathan

From: Jennifer Strickland <jstrickland@mitre.org>
Sent: Tuesday, June 28, 2022 10:42 AM
To: Alastair Campbell <acampbell@nomensa.com>
Cc: 'WCAG list' <w3c-wai-gl@w3.org>
Subject: Re: [EXT] RE: Page break navigation

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Alastair,
If I understood Matt's input correctly, "Is not difficult or infeasible in practice;" is the issue. It sounds like software (i.e., InDesign outputs) isn't quite ready to support the SC. That's why I wondered if tech is ready to support it.
Kindly,
Jennifer

From: Alastair Campbell <acampbell@nomensa.com>
Date: Tuesday, June 28, 2022 at 10:38 AM
To: Jennifer Strickland <jstrickland@mitre.org>
Cc: 'WCAG list' <w3c-wai-gl@w3.org>
Subject: Re: [EXT] RE: Page break navigation
Hi Jennifer,

I'm not certain I understood your point, but the SC is oriented towards the current situation (software), whilst being open to user-agents fulfilling it in future.
Wilco's point was about what happens if some software updates to clash with the SC.

Regarding level, we originally had this at level-A, and a related AAA SC that was about requiring pagebreak locators for some types of content.

I don't think we had a discussion focused on the level, but A seems reasonable (and has been the level approved in previous CFCs) because the SC:

  *   Is about a barrier that cannot be overcome by user's technology (yet, and if it is, it passes);
  *   Is not difficult or infeasible in practice;
  *   Is scoped to specific content;
  *   Doesn't require a change to the look & feel for everyone.

Kind regards,

-Alastair


From: Jennifer Strickland <jstrickland@mitre.org>
Date: Tuesday, 28 June 2022 at 14:41
To: Matt Garrish <matt.garrish@gmail.com>, 'Wilco Fiers' <wilco.fiers@deque.com>
Cc: Alastair Campbell <acampbell@nomensa.com>, 'WCAG list' <w3c-wai-gl@w3.org>
Subject: 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]