List of illustrations

[michael-roe]

(Feature request)

Add a role corresponding to ‘loi’ in the ePub structural semantics. It identifies a section or nav element containing links to the illustrations in the document.

[pkra]

This ARIA issue is probably relevant: w3c/aria#1643

[cookiecrook]

My hot take is that a "list of illustrations" role is needlessly specific. @michael-roe can you add some justification as to why this is necessary for assistive technology use cases?

[TzviyaSiegman]

I agee with @cookiecrook. I think doc-toc can be used with a label.

[michael-roe]

My rationale was along the lines of:
a) Looking at the Project Gutenberg corpus of ebooks (which is the source of books I’m particularly interested in using this for), we see that it is relatively common for books to have both a main table of contents and a secondary navigation section, usually for the illustrations. (Yeah, I ought to present some statistics to justify this)
B) e-readers that automatically find navigation pages in the book could do with some way of knowing that (a) the list of illustrations is a navigation page, and not just some other collection of links; and (b) out of the two navigation pages, the other toc is the main one which should be presented by the e-reader to the user first

so yeah, there are probably other ways to do this.

if there was an example in the spec of using doc-toc twice, with some means of indicating which toc was the primary one, it would make the issue clearer to implementers of dreaded and producers of ebooks.

===

The question of what are the criteria for deciding a role deserves including in the spec is a good one.

[michael-roe]

P.s. I’m inclined to agree that list of illustrations is too specific, even if it was in the ePub structural semantics document. What seems to be needed here is a mechanism to have multiple navigation sections, with one marked as the primary and others as secondary (tabs of specific types of content, such as illustrations, figures, whatever)

[TzviyaSiegman]

@michael-roe I think what you're looking for is reading system functionality. A good place to put this issue would be https://github.com/w3c/publ-cg/issues

[mattgarrish]

e-readers that automatically find navigation pages in the book could do with some way of knowing that (a) the list of illustrations is a navigation page, and not just some other collection of links

This is already defined in EPUB, at least, by the combination of the nav property in the package document manifest and the toc value in an epub:type attribute on the nav element with the table of contents.

That's how reading systems find the table of contents and display it to users; they don't use roles.

I wouldn't put the doc-toc role on a list of whatever (tables, illustrations, examples, videos, etc.). The nav element is already a landmark role, so all you need to do is label it to differentiate it from the other navigation elements. That won't help reading systems, but experience to date is that reading systems are going to ignore everything but the toc and page list unless, as Tzviya says, you can make a case to implement other navigation lists.

In any case, I've tagged this as deferred to a future revision as we're not expanding the publishing roles in 1.1. If you don't feel it's worth pursuing anymore, though, please feel free to close the issue.

[michael-roe]

Ok, I am fairly convinced by the argument that the way to do this is with multiple <nav> elements, with the primary toc distinguished as per the current spec, and no special role attribute on the other nav sections.

I’ll close this issue as resolved if no-one else wants to chime in the issue.