- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Mon, 27 Jun 2022 17:56:21 -0400
- To: Matt Garrish <matt.garrish@gmail.com>
- Cc: Alastair Campbell <acampbell@nomensa.com>, Wilco Fiers <wilco.fiers@deque.com>, WCAG list <w3c-wai-gl@w3.org>
The issues being raised now are identical to what was raised on Sept 5, 2021: overly prescriptive or why Level A etc. SC 2.4.13 Page break navigation for Web content: overly prescriptive? https://github.com/w3c/wcag/issues/2026#issuecomment-915072430 I did not receive sufficient answers but the WG decided otherwise and closed the issue. Thanks, On 6/27/22, Matt Garrish <matt.garrish@gmail.com> wrote: >> Adding in the locators is not trivial. > > > > Yes, it would help to hear the scenarios that are going to trap publishers. > When publishers add page breaks that aren't related to a static source, > they're doing that with the intention of helping all users coordinate their > reading so they add navigation. This SC won't burden them as breaks without > navigation defeat the purpose of what they're trying to achieve. As John > has > pointed out, there are a number of publishers who do this already. > > > >> As discussed previously, CSS break-before/after are not suitable for this > use-case. They adapt to the content so would result in different page > numbers between users. > > > > They also aren't realistic for EPUB as CSS processing isn't a requirement > of > the standard. It only is required when there's a viewport, and not all > reading systems visually render content, so basing pagination off CSS is a > non-starter unless there's another major revision, and that's unlikely any > time soon given the disruption major changes make to the publishing > industry. The other problem with a physical page break mechanism, like CSS, > is that the markers aren't meant to create new pages. They solve the > problem > of pagination varying by reading system by flowing with the content. A > method for synchronizing with static equivalents has to not have the > potential to break current or future rendering. > > > > I also wouldn't say the only benefit here is to EPUB, even if this is > currently where we see it most. There are publications you can read online > that aren't EPUBs (e.g., through Safari books, Project Gutenberg, etc.). > Not > to suggest these sites currently include page breaks, but users should have > the same access regardless of format. We're not trying to force the sites > to > provide this functionality, only ensure that it's available when it's > relevant. There are also other projects going on, like some experiments > DAISY has been doing with books in browsers. There has also been interest > in > using DPUB ARIA roles in Google docs (the request for page header and > footer > roles came from them). So, while identifying pages is not as prevalent > outside of EPUB, I wouldn't say the only benefit is ever going to be for > EPUB. > > > > Matt > > > > -- Sailesh Panchang Customer Success Strategist and Principal Accessibility Consultant Deque Systems Inc 381 Elden Street, Suite 2000, Herndon, VA 20170 Mobile: 571-344-1765
Received on Monday, 27 June 2022 21:56:36 UTC