Re: Page break navigation

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