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