Add page navigation to accessibility features

[mattgarrish]

While reviewing the accessibilityFeature values, I noticed that we have "printPageNumbers" but don't have a value that specifically indicates that page navigation is available.

There's maybe a fine distinction here, but indicating a publication has print page numbers doesn't necessarily mean that it has a page list (although you'd sort of hope that would be the case). Similarly, as we know, if a publication has a page list it doesn't mean that page breaks have to come from a print source, which makes what to specify for that case confusing.

My suggestion is that we introduce an explicit "pageNavigation" value to use when a publication has a page list. It can be paired with "printPageNumbers" to indicate that the publication's static pagination matches a print source.

[GeorgeKerscher]

Might we also add information if there is no print equivalent and the page break locaters are virtual?

[mattgarrish]

if there is no print equivalent and the page break locaters are virtual

It's kind of unfortunate that "print" got into the original value name, but we weren't really thinking of these scenarios back when it was developed.

I guess we could introduce something like a generic "pageBreakMarkers" property, as we have a hole there, too.

The way the vocabulary was originally conceived, print probably should have been a modification of that sort of value: pageBreakMarkers/print

[clapierre]

I like the idea of pageBreakMarkers as a new value for accessibilityFeature, which would be defined as having role="doc-pagebreak" right?

Should we also consider adding "pageList" as an additional value as well which links to these pagebreaks from the nav doc? Just wondering if any publisher would put in the pagebreak markers without linking to them from the nav doc.

Conversely if there was a page list in the nav doc which points to just "id's" within the document with no role="doc-pagebreak" or aria-label=" Page 23. " would the publisher only add "pageList" without "pageBreakMarkers"

[mattgarrish]

Just wondering if any publisher would put in the pagebreak markers without linking to them from the nav doc.

I can't imagine why, as adding the page list is easier than the page breaks. It would also violate the forthcoming WCAG SC that requires a page list when markers are present.

would the publisher only add "pageList" without "pageBreakMarkers"

Yes, markers mean the locations are present in the content so could, for example, be announced by an AT to find out what page you're currently on. You can have a page list without markers if, as you say, you just link to IDs on select elements.

[LaZay]

As a matter of fact, pageNavigationand printPageNumbersserve different needs.

pageNavigationis dedicated to accessibility and assistive technology. The nav element that defines it might not be displayed to sighted persons. <nav epub:type="page-list" role="doc-pagelist">

printPageNumbersis for everybody. It is not restricted to born accessible EPUBs. It may interest not accessible EPUB too, for a use in school typically, to guarantee equivalent page numbering between paper/digital medium in class.

[LaZay]

Explicit page break markers must be set into the content to serve both needs of printNumbers and pageNavigation.

<span epub:type="pagebreak" id="page_43" title="43" role="doc-pagebreak"/>

It is a common base, for two different uses.

[clapierre]

I support the addition to add the accessibilityFeature "pageNavigation" and have not see any publishers add in page break markers without linking to them from a Page List.

@LaZay

<span epub:type="pagebreak" id="page_43" title="43" role="doc-pagebreak"/> Using title is not recommend it is best to use aria-label instead.

[LaZay]

Actually, for our textbooks, we produce some unaccessible FXL EPUBs so far, with all the <span role="doc-pagebreak"/>, but without <nav epub:type="page-list" role="doc-pagelist">. The reading system does not need anything else to provide page navigation for sighted persons. Did I miss something?

[LaZay]

@title was supposed to be more generic, in order to be used by sighted and unsighted persons. As born accessible EPUB must be designed for both audience. Is that wrong?

[clapierre]

@title should never be used except on an iFrame tag, title is mainly used for tooltips upon hover, but most publishers don't visually show the page numbers so how could you even hover to get at the tooltip. This is why @aria-label should be used instead. There is also inconsistent implementation of @title with assistive technologies however @aria-label is well supported by all assistive technologies.

[LaZay]

Thanks for this explanation. I am still perplexed, though. It was specified as @title in http://idpf.org/epub/a11y/techniques/techniques-20170105.html#page-001. It has been changed for @aria-label indeed in https://www.w3.org/TR/epub-a11y-tech-11.

Some eBook reading systems display the page number at the bottom or on the side of each page. The decision for display is made by software publishers (not by publishers unfortunately). This ergonomy is very specific to reading systems, as they are specially designed for books. The display is completely different from navigators designed for content without pagination.

Inclusive publishing must include unsighted persons, but also sighted persons !... :-) A double production is not sustainable. Only a unique born accessible production is sustainable. Good practices for unsighted persons are not supposed to introduce any regression for sighted persons. Further more, good HTML practices are much easier to sell to our companies and to our subcontractors. Dedicated additional ARIA attributes mean additional work, and costs. My understanding of ARIA attributes is that they are required only when semantic information is missing in the HTML. Which is not the case, as it is already available ont the page's @title. Let's play it win-win to make it happen. In this particular case, maybe the effort should be assumed by the assistive technologies instead, so that they can use the existing @title on page markers?

[mattgarrish]

It was specified as title in

The practice of specifying page breaks using the epub:type and title attributes goes back to 2010 when aria-label wasn't well supported, either. It also didn't make sense to use aria-label because we didn't have a role. The theory was the title attribute would be used to identify the page number, but the reality is that epub:type has never been used by assistive technologies. The guidance has been updated to reflect the lack of implementation.

Inclusive publishing must include unsighted persons, but also sighted persons !

True, but you can't hover something that occupies no space, so how would sighted users benefit from the markup pattern even if they are reading on a device with a mouse?

If the issue is a reading system only recognizing title, then we should put in a bug report.

Further more, good HTML practices are much easier to sell to our companies and to our subcontractors.

But as @clapierre mentioned above, this isn't a good practice, even if it does work with name computation algorithm. The HTML spec even says:

Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification (e.g., requiring a pointing device such as a mouse to cause a tooltip to appear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet).

https://html.spec.whatwg.org/multipage/dom.html#the-title-attribute .

[LaZay]

The point is precisely that page number is not managed as a hover by eBooks reading systems. It is displayed right away in the page navigation bar. This page number is based on the page breaks tags, when the printPageNumbers is preserved (for everybody, not only for accessibility sake). <span epub:type="pagebreak" id="page_43" title="43" role="doc-pagebreak"/> or <span epub:type="pagebreak" id="page_43" aria-label="43" role="doc-pagebreak"/> or <span epub:type="pagebreak" id="page_43" title="43" aria-label="43" role="doc-pagebreak"/> Otherwise it is dynamically calculated.

It is not based on any nav element belonging the landmarks (which was the initial question) that implement the pageNavigation service. This is totally dedicated to assistive technologies instead if I understood the pagelist landmark properly. <span role="doc-pagebreak"/>, but without <nav epub:type="page-list" role="doc-pagelist"> Here is a non accessible eBook with printPageNumbers but no pageNavigation . EPUB OPF metadata must report this.

[mattgarrish]

The point is precisely that page number is not managed as a hover by eBooks reading systems. It is displayed right away in the page navigation bar.

Sure, but you said that only the title attribute should be used, despite it not having any appreciable benefit to sighted users in this case based on its inherent functionality. What you're pointing to is a reading system behaviour that can be implemented in a variety of ways, not just off title, and, in fact, has to to account for the different ways page breaks can be represented.

The problem with epub:type and title or aria-label is that the value computation was never documented. We loosely based it on how ARIA works and hoped developers would account for the variations. That's problematic for all these kinds of cases, which are all valid:

<span epub:type="pagebreak" title="34" aria-label="23"/>
<span epub:type="pagebreak" aria-label="" title="12"/>
<span epub:type="pagebreak" title="34">23</span>
<span epub:type="pagebreak" aria-label="23">45</span>
<span epub:type="pagebreak" aria-label="23" title="34">45</span>
etc.

Nothing in EPUB says how to interpret these. Switching to ARIA role at least provides its name calculation rules, so it's a much better pattern to use. You can still use the title attribute, but it's generally considered the least ideal solution due to poor uptake.

If digital editions doesn't handle aria-label with a role in a simlar fashion to epub:type and title, then we should be looking at getting that fixed. It's not a good case in itself for perpetuating a poor markup pattern.

There is also a task force in the EPUB 3 working group looking at page markers and how to implement them. From their discussions, I don't get the impression that digital editions is indicative of how all reading systems work. There are others that require the presence of a page list before they will display the static pagination.

But, again, this is a problem of a lack of standardization and much bigger than this specific issue.

We're also straying off topic, as this isn't the place to solve the markup patterns for EPUB. The metadata doesn't exist to enforce accessibility but to report on it. In this case, the presence of page numbers is distinct and separate from the presence of a page list and we should account for both.