RE: [EXT] RE: Page break navigation

> Unless I'm misunderstanding it does sound like this may need adjustments
to software that don't yet exist today. 

The exporting of page breaks isn't a trivial task right now, but page
navigation is well supported within the epub ecosystem for books that have
breaks and a page list.

 

There are two types of pagination within epub reading systems to be aware
of, though. By default, you will get pagination that the reading system
provides. This is based on their own algorithms and is often related to how
the content is chunked into virtual pages for rendering. This kind of
pagination is unreliable as it will differ across devices and even on the
same devices if users have different display settings. There are no
"markers" in the content associated with these pages.

 

When a page list is provided, the pagination becomes static so can be
consistently accessed across devices. Sometimes reading systems add static
page navigation in parallel with their own virtual pagination, and sometimes
they use the information in place of their own algorithmic approaches. The
problem is that if you have to provide the information to get the static
locations, as it's not a trivial task for a reading system to obtain all the
page breaks across an EPUB that might consist of tens or hundreds of
individual documents.

 

> Would it make sense to make this a Level AA

 

We defer to this group on what level this makes the most sense at. Either
level works for us.

 

Matt

 

 

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