RE: Page break navigation

 

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

 

Navigation by table of contents is equally important, but it doesn't provide
the same level of granularity. A student who can only reach the nearest
heading then has to manually find their way to the location within the
chapter or section.

 

The problem with the multiple ways success criterion is that it doesn't
require anything in particular; it's too general. There are always multiple
ways to navigate an EPUB between the required table of contents and the
linear reading order, for example. Having this success criterion promotes
this particular need for environments where mixed print/digital use is
common.

 

I don't recall this success criterion is prescriptive about how linking to
the pagination has to occur, either. If it makes more sense on the web to
offer some other alternative, then nothing makes that wrong. You could have
a "jump to" box that allows someone to input the page number to move to the
destination; it doesn't have to be a big list of links. I'm not sure about
using the table of contents, though, as that would probably bloat it and
make it useless for navigation, especially when hundreds or thousands of
page number are in it. But if your only page markers are the start of each
section, then maybe you can combine the heading link and page link?

 

And correct me if I'm wrong, but doesn't "mechanism" also mean AT could
provide the functionality on the web? If, in the future, they were to
provide a list of all doc-pagebreak identified markers to navigate to,
wouldn't that remove the need to do anything special for web publishers? (Of
course, that's speculative and far off, and maybe only appropriate for
single-page documents.)

 

Matt

 

 

From: Alastair Campbell <acampbell@nomensa.com> 
Sent: June 24, 2022 1:44 PM
To: Wilco Fiers <wilco.fiers@deque.com>
Cc: WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
Subject: Re: Page break navigation 

 

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