Re: Page break navigation

Wilco writes:

> *As a result, this success criterion is going to require organizations to
add page navigation to documents that do not benefit from it in any way.*

I'm sorry Wilco, that is not what the proposed SC says. It instead says
**if/when** a page-break indicator is there:

*For web content with* page break locators
<https://w3c.github.io/wcag/guidelines/22/#dfn-pagebreak-locators>, a
mechanism <https://w3c.github.io/wcag/guidelines/22/#dfn-mechanism> is
available to navigate to each locator.


I do not read this as mandating page-breaks, sorry. And the normative
definition of a page break
<https://w3c.github.io/wcag/guidelines/22/#dfn-pagebreak-locators>
(editorial note: perhaps we should hyphenate page-break to align with the
attribute values?) says:

programmatically determinable
<https://w3c.github.io/wcag/guidelines/22/#dfn-programmatically-determinable>
destination
markers that are arranged in a meaningful sequence to represent a locator
serving the same purpose as *page breaks in a printed document*.


> *The success criterion as written is applicable to every document with a
page break locator, regardless of length, or the granularity of its table
of content.*

Wilco, do you have *any *examples of content that does not originate as, or
is intended to replicate, a print document that contains a page break
indicator? And by that I mean the ARIA attribute of role="doc-*pagebreak"*?

While I understand the potential edge-case here, I also believe you are
over-inflating the possibility that this will impact non-book-like content,
and I for one would like to see *some *empirical evidence of that
possibility. Because while we can't completely rule out mis-use of that
attribute/value pair (i.e. accidental insertion into content), it is a very
specific attribute and value string, and I'm struggling to believe mis-use
would be common enough to worry about. (Question: I wonder out loud if
adding a minimum quantity would help ease this concern, i.e. *"**For web
content with 5 or more page break locators, a mechanism...")*

> *Only if you're accessing your textbook as an EPUB, through a web viewer
may you actually see a benefit from this success criterion*

ePub content can be consumed by numerous stand-alone reading systems
<https://www.engadget.com/amazon-kindle-supports-epub-format-002501848.html>
that are not general-purpose web browsers (although they all do use a
browser rendering engine under the hood). Additionally, the ePub/publishing
industry is moving towards requiring page-break notation, even for
digital-first books. Benetech's GCA Certification Program for ePub
<https://bornaccessible.benetech.org/global-certified-accessible/> now has
a standing requirement:

Page numbers in eBooks are extremely important for accessibility. Without
embedded page markers, either Go To Page functionality is disabled
completely, or it is up to the reading systems to create virtual page
numbers that would be different on every reading system. Therefore, users
would not be able to go to the same page within the same EPUB on different
reading systems. *It has always been GCA's intent to enforce having page
numbers to pass certification.*


For these reasons I believe this SC should be added to WCAG 2.2.

JF

On Mon, Jun 27, 2022 at 6:00 AM Wilco Fiers <wilco.fiers@deque.com> wrote:

> Hey Alastair,
> I am fully on board with a success criterion that requires page navigation
> for textbooks. I do not think the success criterion, as proposed, does that
> anywhere near as well as it should.
>
> The success criterion as written, on the one hand is far broader than
> textbooks. The success criterion as written is applicable to every document
> with a page break locator, regardless of length, or the granularity of its
> table of content. That is far broader than is necessary to address the
> "text books in education" use case. As a result, this success criterion is
> going to require organizations to add page navigation to documents that do
> not benefit from it in any way.
>
> At the other end, the success criterion is so narrowly defined that it
> does not apply to other formats with which text books may be published. As
> a result, WCAG 2.2 doesn't actually add a new guarantee that textbook
> navigation has actually become more accessible. Only if you're accessing
> your textbook as an EPUB, through a web viewer may you actually see a
> benefit from this success criterion. And even then, only if the
> doc-pagebreak element has an ID attribute.
>
> This success criterion does not do what it says on the tin; make
> navigating multi-page documents accessible. It only applies to EPUB, and
> only EPUBs that have their page breaks done in a very specific way. It can
> easily be circumvented. And it relies on the assumption that there will
> never be any other way to indicate page breaks even in EPUB (like adopting
> CSS break-before / break-after).
>
>
> On Fri, Jun 24, 2022 at 6:45 PM Alastair Campbell <acampbell@nomensa.com>
> wrote:
>
>> Hi Wilco,
>>
>>
>>
>> Starting a separate thread, chair hat off, replying from the perspective
>> of following the SC from the beginning:
>>
>>
>>
>> *> *In my opinion the user need for the success criterion as written has
>> not been sufficiently established.
>>
>>
>>
>> This requirement came from the EPUB group, and everyone we’ve heard from
>> that has worked in education has said that this is a problem.
>>
>>
>>
>>
>>
>> > While it is certainly true that for example, students need to be able
>> to navigate to specific pages in digital text books, it doesn’t necessarily
>> follow that every web page containing page break indicators poses a
>> significant accessibility barrier unless page break navigation is added.
>> For example, if the web page has only one or two page break locators.
>>
>>
>>
>> The way the SC is scoped, it only applies if people intentionally add
>> page break locators. It isn’t something that happens by accident. I can’t
>> see a scenario where someone would accidentally add one or two
>> page-break-locators. If they did, then it’s essentially a bug and could be
>> removed.
>>
>>
>>
>>
>>
>> > There is also no allowance for alternative forms of navigation within
>> the page, for example navigating a page by headings through a table of
>> contents could address the same user need. In that way the success
>> criterion is overly prescriptive. Unlike for example 2.4.5 Multiple Ways
>> and 2.4.1 Bypass Blocks, which allow for different solutions.
>>
>>
>>
>> Going back to the first point, the scenario it is trying to tackle is the
>> one where page numbers are available. If they are made available AND the
>> author(ing workflow) has included markers of those pages, there is an
>> intention there. Headings may well provide another method of navigating,
>> but if (non-disabled) people can refer to the page numbers, it follows
>> there should be a way for someone low-vision or blind to get to them.
>>
>>
>>
>> > Lastly, I believe this success criterion is a poor fit for WCAG 2.2. It
>> is written in such a way that it can only be applied to EPUB, regardless of
>> the much broader user need for inner-page navigation for large documents.
>> WCAG 2.2 is designed as a technology agnostic standard. Success criteria
>> should not be constrained to apply to only one technology.
>>
>> There may be a broader need for inner-page navigation, but we haven’t got
>> an established user-need for that. It could be that the current
>> implementations of things like tables-of-contents based on headings work
>> well, including for accessibility.
>>
>>
>>
>> However, we do know there is a need for page navigation in certain
>> circumstances. I agree that the scope is quite narrow, but that is a good
>> thing in this case because it scopes the SC to the circumstances where we
>> know it is needed.
>>
>>
>>
>> I also feel like a broken record but: EPUB readers have page navigation
>> built-in (i.e. fulfil the “mechanism is available” wording). This SC has an
>> effect when those documents type of documents are transposed to
>> browser-based situations.
>>
>>
>>
>> Kind regards,
>>
>>
>>
>> -Alastair
>>
>
>
> --
> *Wilco Fiers*
> Axe-core & Axe-linter product owner - WCAG 3 Project Manager - Facilitator
> ACT Task Force
>
>
>

-- 
*John Foliot* |
Senior Industry Specialist, Digital Accessibility |
W3C Accessibility Standards Contributor |

"I made this so long because I did not have time to make it shorter." -
Pascal "links go places, buttons do things"