Re: [EXT] Re: Page break navigation

Hi John and Wilco, et al,
I was curious, why is this set as a Level A when it is a big if?
Is it due to impact on users of particular technology?
Thank you,
Jennifer

From: John Foliot <john@foliot.ca>
Date: Monday, June 27, 2022 at 9:55 AM
To: Wilco Fiers <wilco.fiers@deque.com>
Cc: John Foliot <john@foliot.ca>, Alastair Campbell <acampbell@nomensa.com>, WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
Subject: [EXT] Re: Page break navigation
Hi Wilco,

> In a technology agnostic standard, why would we have a success criterion that is so constricted it applies to EPUB, but not to online PDF, Word, or Google Document viewers?
So, I think here you are mixing apples with oranges. Nothing about the SC speaks directly to ePub at this time, however that is currently where the real need is. Again, this SC is not mandating page-breaks, it is only saying that when present, a navigation mechanism must be present. That to me is a far cry from mandating page-breaks on all 'book-like' content despite the final file format.

Additionally, the ARIA role of "doc-pagebreak<https://www.w3.org/TR/dpub-aria-1.1/#doc-pagebreak>" is applicable to all markup languages (ARIA itself being mark-up language agnostic - AFAIK, that includes ODF -  Open Document Format), so in theory adding that attribute to ODF-based files such as .docx is certainly do-able, and other ebook formats such as .mobi could also contain aria attributes (all .mobi pages are encoded in XHTML as well).

What we DO NOT have today however is a mandate (at least at the W3C) to ADD this attribute to that kind of content - which again is not what this proposed SC is seeking to do. And so in that regard, the only 'condition' here is that WHEN you use the page-break markup, ensure that it is supported with a navigation mechanism - it's a huge *IF* statement that falls short of demanding page-breaks, and contrary to your assertion that this is for ePub only, the ARIA attribute can today be used on multiple file formats.

JF


On Mon, Jun 27, 2022 at 9:04 AM Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>> wrote:
Hey John,
Setting a minimum number of pages would indeed help, as would allowing a table of content that is sufficiently granular. We'll have to define what "sufficient" means there, but that's doable.

As you point out there are online EPUB viewers that have this problem, my third concern is that as written, only those EPUB viewers would be subject to this SC, and only those that do not strip out doc-pagebreak nodes, which they easily could do. In a technology agnostic standard, why would we have a success criterion that is so constricted it applies to EPUB, but not to online PDF, Word, or Google Document viewers? To someone needing to access their textbooks it makes absolutely no difference what the underlying technology is.




On Mon, Jun 27, 2022 at 2:34 PM John Foliot <john@foliot.ca<mailto:john@foliot.ca>> wrote:
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<mailto: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<mailto: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
Error! Filename not specified.



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


--
Wilco Fiers
Axe-core & Axe-linter product owner - WCAG 3 Project Manager - Facilitator ACT Task Force
Error! Filename not specified.



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

Received on Monday, 27 June 2022 14:11:22 UTC