[EPUB 3.3 RS] [suggestion] Navigation Document Processing

[gregoriopellegrino]

The navigation document for EPUB 3 is for all intents and purposes HTML.

This means that it can contain within it attributes related to ARIA (e.g. aria-label, etc.) or the lang attribute. I think it would be important to point out to reading solutions that if these attributes are present (because they were intentionally inserted by the creators), they should be honored when the navigation document is shown in the User Interface of the application.

https://www.w3.org/TR/epub-rs-33/#sec-nav

[dauwhe]

See #1191... I would love it if more of the content of nav was used by reading systems. But many of them appear to just pull the href and the text value of the link, and omit everything else as it's put into a non-HTML data structure.

[iherman]

See #1191... I would love it if more of the content of nav was used by reading systems. But many of them appear to just pull the href and the text value of the link, and omit everything else as it's put into a non-HTML data structure.

In particular #1191 (comment), which was why #1191 was closed.

That being said, the section referred to already contains a list of items as SHOULD-s or MAY-s, adding that extra item may be consistent

[mattgarrish]

We don't support ARIA attributes in the content model, so I think we'd be complicating things by requiring reading systems to process them.

If a link contains non-textual content, the requirement is that the title or alt attribute on the element include the text content to use in the link. And if the non-textual content is in an embedded element, then the a or link element has to have a title.

It would be better to reference across to these existing rules if we need to explain link label extraction. That may only require an additional link in the first bullet on the word "links".

[gregoriopellegrino]

That being said, the section referred to already contains a list of items as SHOULD-s or MAY-s, adding that extra item may be consistent

+1

Ok for the formatting issue, but I think the language attribute can be significant for accessibility (and not just usability). I know this first hand when I use English text-to-speech to read text in Italian, it takes a lot of practice to understand it :).

[iherman]

The issue was discussed in a meeting on 2021-08-27

List of resolutions:

• Resolution No. 3: Add clarifying link to authoring specification, label issue as EPUB next and close issue 1775

View the transcript

3. Navigation Document Processing

See github issue #1775.

Dave Cramer: this is related to things we've discussed in the past. Our nav is HTML, so it can include ARIA attributes, lang, etc.
… gpellegrino proposes that we remind RS that they should honor these sorts of attributes when they present nav content in UI
… but some RS just strip everything except the text value of the stuff in nav

Hadrien Gardeur: I'm worried about this. There are very good reason why RS do that.
… if we change this RS cannot use native UI elements to present nav
… would have to be a webview
… I don't think what is being suggested is achievable

Matt Garrish: I agree that we don't want to go here, but for a different reason. The nav was meant to make things simple for RS. Not sure its a good idea to expand complexity at this point.

Gregorio Pellegrino: I understand the concerns. Can I amend the issue to just ask that RS adhere to lang attribute? Or to tell authors not to use those attributes in the nav, because they may not be used by RS. So author can find some way around this limitation.

Dave Cramer: i agree with Hadrien's concerns here. If RS wants to take info in nav and process it into native UI elements, we are not preventing them from doing anything. They can look for XML lang if they want.
… and then what they do with that is up to them
… to gpellegrino's point about advising authors, I don't think that's a good idea because we also have the idea of displaying the nav in the spine, and ensuring that it gets presented as HTML, and where all these attributes will be honored

Hadrien Gardeur: i think it comes back to the fact that we're trying to serve two goals: 1) machine readable view, and 2) document view/webview
… but trying to do both in same document we're always going to have conflicts between those goals
… i don't think we can solve both needs with single document
… the only way to fix it is to basically have one thing that is meant to be processed, and another thing meant to be rendered the way it would be on the web
… this is how I'd deal with this eventually

Murata Makoto: Yes, I was writing an email about the use of ruby in nav docs to my colleagues in JDC.

Matt Garrish: i wonder if what is missing here is that there are requirements on how to create the text label. It's in the RS spec.
… maybe we could link to those?

Dave Cramer: yeah, that kind of makes sense

Brady Duga: in terms of lang, we're probably right by chance because people usually read books in the same language that their RS is set to. But we've never received a complaint about this.
… but it is a good point that was made by gpellegrino

Dave Cramer: we're not in a position to change the processing rules, even if using the same doc for processing and rendering removes duplication
… i would close this, but incorporate mgarrish suggestion to link back to RS spec

Gregorio Pellegrino: may I add the issue to epub next so we don't lose track of it?

Dave Cramer: yes

Matt Garrish: maybe the point about lang is a statement we can make in the a11y section. Just to say that any UI should be accessible.

Dave Cramer: yes

Proposed resolution: Add clarifying link to authoring specification, label issue as EPUB next and close issue 1775 (Wendy Reid)

Gregorio Pellegrino: +1

Wendy Reid: +1

Deborah Kaplan: "1

Matt Garrish: +1

Deborah Kaplan: +1

Toshiaki Koike: +1

Brady Duga: +1

Dave Cramer: +1

Tzviya Siegman: +1

Matthew Chan: +1

Bill Kasdorf: +1

Masakazu Kitahara: +1

Dan Lazin: +1

Murata Makoto: +1

Avneesh Singh: +1

Ben Schroeter: +1

Resolution #3: Add clarifying link to authoring specification, label issue as EPUB next and close issue 1775

George Kerscher: +1