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