Additional text or hints on what would become pagelist targets.

[iherman]

(This is a spin-off of #339.)

The goal is to add some text, either in the draft or in a separate best practice document, on would constitute a suitable target for pagelist links.

[iherman]

Alternative that were mentioned in #339:

• Using a data-xxx attribute for that purpose (see Added the pagelist entry #339 (comment), but also problems with the approach expressed in Added the pagelist entry #339 (comment))
• Using existing (or maybe define additional) attributes, like doc-pagebreak, from DPUB-ARIA.

Further relevant comments are: #339 (comment), #339 (comment), #339 (comment), #339 (comment), #339 (comment), #339 (comment)

[JayPanoz]

Aren’t custom data-* attributes meant for authors? I mean, from the LS:

Custom data attributes are intended to store custom data, state, annotations, and similar, private to the page or application, for which there are no more appropriate attributes or elements.

These attributes are not intended for use by software that is not known to the administrators of the site that uses the attributes. For generic extensions that are to be used by multiple independent tools, either this specification should be extended to provide the feature explicitly, or a technology like microdata should be used (with a standardized vocabulary).

and, later:

User agents must not derive any implementation behavior from these attributes or values. Specifications intended for user agents must not define these attributes to have any meaningful values.

[Edit] So yeah, what Daniel said.

[llemeurfr]

Moving #223 discussion there, let's

• request the use of a doc-pagebreak attribute.
• give a sample showing its use on a span, like in this Daisy page, used with an aria-label for the page number.
• note that if the element supporting doc-pagebreak is so that the page number is a text node (and not an attribute), users will usually hear and view the page numbers in the flow of text, which may be a nuisance.

[lrosenthol]

doc-pagebreak only lets you specify *one* element on a page while not providing *any* information about which page the element is associated with. Additionally, it doesn't address the situation where a block level element spans multiple pages (eg. a table).

…

On Fri, Oct 12, 2018 at 11:04 PM L. Le Meur ***@***.***> wrote: Moving #223 <#223> discussion there, let's - request the use of a doc-pagebreak attribute. - give a sample showing its use on a span, like in this Daisy page <http://kb.daisy.org/publishing/docs/navigation/pagelist.html>, used with an aria-label for the page number. - note that if the element supporting doc-pagebreak is so that the page number is a text node (and not an attribute), users will usually hear and view the page numbers in the flow of text, which may be a nuisance. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#341 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE1vNdWBqPw8GrMEW9BAo6rbcviDD_OEks5ukKF1gaJpZM4XY6eQ> .

[laudrain]

@lrosenthol the pagebreak in content is an empty point in content. It doesn't mark an element.
As specified by DAISY, it is encoded today as an empty span with attributes:
<span role="doc-pagebreak" id="pg24" aria-label="24"/>

[iherman]

It does not look like there is any addition proposed to the draft. Propose closing...

@TzviyaSiegman @wareid @GarthConboy

[llemeurfr]

@laudrain please look at http://kb.daisy.org/publishing/docs/navigation/pagelist.html, QA "Should I include the page numbers as content or empty elements?": the answer is not as clear as you are stating.
The issue is that reading system can face either
<span role="doc-pagebreak" id="pg24" aria-label="24"/>
or
<span role="doc-pagebreak" id="pg24">24</span>
or a mix of the two solutions.

Without special treatment, in the second variant, "24" will be displayed somewhere, maybe in the middle of a sentence.

I seems to me more effective to push explicitly the use of the first variant in best practices, as the title of this issue suggests.

[danielweck]

@llemeurfr

Without special treatment (...)

Right, I imagine you are alluding to styling rules such as:

[role~="doc-pagebreak"] {
    display: none;
}

or:

[role~="doc-pagebreak"] {
    visibility: hidden;
    overflow: hidden;
    position: absolute;
    width: 0;
    height: 0;
}

(which could be defined at the reading system level by the user-agent stylesheet, but more likely in the case of Web Publications as authored styles)

The problem with the former CSS technique (display: none) is that although the target "page breaks" / DOM elements+ids can in principle be hyperlinked into, they will in fact not be rendered so there will be no visual coordinates where to scroll/focus the content viewport. In other words, this effectively removes "page breaks" from the render tree of targeted documents, but in turn this has the unfortunate side-effect of disabling "page list" links / navigation. Note that AT/screen-readers will (appropriately) not perceive display: none content. Importantly, also note that the hidden HTML attribute has the same effect, unlike aria-hidden.

The latter CSS technique preserves "page list" links / navigation, but then content creators might as well author documents using the less verbose "empty elements" markup, in the first place. However in this case note that AT/screen-readers will perceive the aria-label, unless aria-hidden is used.

Bottom line: the authoring guidelines should ensure that when page-break markup is "hidden" from view (in the loose sense of the term), hyperlinks still work.

[laudrain]

Conceptually, the page break is a point in the HTML content.
Having the page number as content is truely paperlike and IMO has nothing to do in a WP (nor in an EPUB3 today).
And this pagebreak point can even be in the middle of a word.

In EDUPUB, which had a11y features, it was clearly stated as an empty span.
http://www.idpf.org/epub/profiles/edu/EDUPUBContentModel/ContentModel.html#pagebreak
I suppose then that AT are working with that empty span element.
@danielweck is there an a11y issue with an empty span?

[TzviyaSiegman]

I am not sure what is being requested here. It sounds like best practices, not spec.

[mattgarrish]

It's definitely not spec-able, as it assumes that page lists are linking into HTML, when you could use a page list with media fragments to jump the user into audio or video (although only the latter seems to be supported right now). A purely image-based publication wouldn't have anything at the destination, either (other than the image, of course).

@laudrain You're actually pointing to one of the input documents. The edupub spec didn't take a position on how to format page breaks. See http://www.idpf.org/epub/profiles/edu/spec/edupub-20150115.html#h.3zalt8ku3l0r

[danielweck]

@laudrain

@danielweck is there an a11y issue with an empty span?

Not per-se, but I mentioned aria-label vs. aria-hidden to illustrate the fact that authoring guidelines / good practice for "page breaks" also depends on how content creators want their users to experience the document flow (i.e. with or without interspersed visual+aural rendering of page markers). Reading systems could hypothetically (some do) customize/override this behaviour based on user preferences, but in the world of user agents / Web Publications, I would expect authors to define the user experience (for example by including affordances to switch page breaks on/off ... which would probably require a combination of Javascript and CSS, maybe even DOM manipulations).

Anyway, going back to the issue at hand here: I don't think that this specification should normatively prescribe that hyperlink target elements must carry the role=doc-pagebreak attribute, and certainly not how the markup should be structured. This belongs in authoring guidelines, in my opinion. That being said, there can be an informative note about role=doc-pagebreak and a reference to an external document that describes its use? (I'm biased, I like the DAISY Knowledge Base ... but I don't know if this is adequate in the long run for the WP specification)

[iherman]

Before closing... we should have some sort of a list for issues that are to be listed in an authoring guidelines. Just that we would not loose these things and discussions...

@GarthConboy @TzviyaSiegman @wareid

[avneeshsingh]

The objective of adding aria role pagebreak to pagelist targets was to enable reading systems to implement skippability. Which means that reading systems can implement functionality to hide the targets (span elements with pagebreak role) if user choose to do so, otherwise these are left inside the logical reading order.
So, the question is, do we want WP to support functionality like skippable structures. It is important for sync media implementation. On the other hand for usual WP (with no sync media) it can be a debatable issue.

[wareid]

As discussed in the call on Dec 3, closing this issue as it is for now. If a new issue arises in the sync media work, we can address it then with a new issue that outlines what changes are needed.