W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2022

Re: [EXT] RE: Page break navigation

From: Jennifer Strickland <jstrickland@mitre.org>
Date: Tue, 28 Jun 2022 14:41:41 +0000
To: Alastair Campbell <acampbell@nomensa.com>
CC: 'WCAG list' <w3c-wai-gl@w3.org>
Message-ID: <SA0PR09MB7002E7C21303A44CA7FC58D7B0B89@SA0PR09MB7002.namprd09.prod.outlook.com>
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]
Received on Tuesday, 28 June 2022 14:41:56 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 28 June 2022 14:41:58 UTC