Add requirement in EPUB Accessibility specs for Aligning TOC in Nav Doc with the reading order

[avneeshsingh]

Refering to #1283 , in EPUB 3.3 specs we have relaxed the requirement for TOC in Navigation Document to align with the order of spine, and have referred to Ace by DAISY to check it because it is more of accessibility issue.

Therefore we should add this is a requirement in EPUB Accessibility specifications. In the normative specifications we should have the requirement that the entries of TOC in the Navigation Order should be aligned to the reading order of the content. And in the techniques document we can explain, how to implement it with respect to the entries in the spine and also with respect to headings on the same Content Document.

My personal inclination is to have it as a "MUST" in the EPUB Accessibility specifications, but I would like to know there is a strong case to have it as "SHOULD".

[iherman]

My personal inclination is to have it as a "MUST" in the EPUB Accessibility specifications, but I would like to know there is a strong case to have it as "SHOULD".

This leads to a more general question. Would it be appropriate to have the A11y specification to impose a stricter requirement of this sort than the content specification spec? If so, what are the criteria for this? (E.g., do we want to extend the A/AA/AAA levels to the A11y spec and say that 'SHOULD' refers to 'A' and 'MUST' to 'AA'?

I think having a strong harmonization of the A11y and the EPUB content specs, to form a coherent specification, should be our goals.

[shiestyle]

Because there are many use cases which TOC should be better to be ordered by the difference of spine orders. And there are already many EPUB files by replicated from paper books that order of Navigation Document and order of spines especially in Japan.

We don't have intention to break the story order but if the spines are independent topics, reconstructed TOC including multiple TOC may be convenient for readers.

Our target contents are not novels or story books but magazines or cook books etc.

The mismatch order of NavDoc and spines doesn't mean that story will be broken and the same order of the two doesn't guarantee that story will not be broken. The consistency of the story should be kept by the order of spines when generating the EPUB file.

Spines should be used for sequential access and NavDoc may be used for not only jumpy access but also random access to the digital content.

[murata2makoto]

The technical committee of the Japanese DAISY Consortium believes that this topic is just the tip of an iceberg. There are at least three types of inconsistencies:

• Inconsistencies between the navigation document and the spine element
• Inconsistencies between MO documents and content documents
• Inconsistencies between MO documents and the spine element

Different structures define "next" differently. Users are confused. Implementors have to mediate conflicting structures. We have some GitHub issues (in Japanese) about such problems.

We are wondering if EPUB 3.3 RS should provide a framework for navigation operations and identify confusing scenarios caused by inconsistencies.

[murata2makoto]

@iherman

This leads to a more general question. Would it be appropriate to have the A11y specification to impose a stricter requirement of this sort than the content specification spec?

Sure. Doesn't WCAG impose stricter requirements than HTML?

[mattgarrish]

My personal inclination is to have it as a "MUST" in the EPUB Accessibility specifications, but I would like to know there is a strong case to have it as "SHOULD".

Note that the requirement was only reduced to a recommendation, so the core specification still says it is a "should" to align the two. If we're adding this to the accessibility specification, we have to make it a requirement again ("must").

do we want to extend the A/AA/AAA levels to the A11y spec and say that 'SHOULD' refers to 'A' and 'MUST' to 'AA'

It doesn't quite work this way. You set a requirement for a specific level, so either it's required to meet level A (and consequently any higher level) or required to meet level AA (and higher).

I don't know if a toc that mismatches the content order should be considered inaccessible or not. Having had a similar discussion about sequences out of order in the spine with the wcag people, I suspect they would categorize this as a general usability problem for all readers, not specifically an accessibility issue. No one group of readers will have any better idea than another why the entries are out of order, or if the revised ordering actually makes more sense for its purpose.

But, I agree we should be more specific which level our requirements match, though, as it's implied right now that they're all level A.

[Doktorchen]

At least for books with non-linear content, that can have multiple alternative reading orders it turns out currently to be a good idea to rerefence only the first documents with linear reading order in this official XHTML nav document and put the real lists of content in a separate file, referenced by this nav document to avoid confusion or problems with such requirements. Similar to the toc.ncx file, the toc.xhtml nav document becomes an almost useless residual for the audience in those cases, because they anyway have to use another document with the proper and complete list of content instead.

To get this fixed, one would have to align the spine element content to possible multiple reading orders with choices. Without this, such a requirement might be only obvious for pretty simple digital books, that really have only exactly one reading order, for example simple digital replicates of older printed books. Newer digital books may provide other, different approaches to access the content for different reasons for people with different capabilities, for example to enable better accessibility for some groups depending on their preferred strategies to learn in educational books.

It would be pretty good for accessibility, if the spine element content could reflect these different approaches or multiple or alternative reading orders, but currently the spine content is only a linear list without choices oder sublists, therefore it does not cover those needs. Typically digital content has no spine as a printed book consisting of fixed pages has. And in some cases even for printed books such a spine is only a pure technical limitation, that has overcome with digital content. To stuck into technical structures of printed, paged books is a barrier, an acessibility issue for some content and audience. To inherit these problems or limitations artificially into digital books mainly means to create accessibility problems by design or specification. Any navigation document reflecting only this insufficient linear order will only fail to provide a meaningful representation of the content of such books.

[GeorgeKerscher]

I agree with these thoughts. For titles that have several approaches to navigating the document, perhaps the nav doc should reference the list of alternatives.

For a tour book of Paris, you might have:

Churches-toc

Museums TOC

Bakeries TOC

Dinner restaurants TOC

Etc.

[mattgarrish]

and have referred to Ace by DAISY to check it because it is more of accessibility issue

If we're adding this as an epub success criterion, it'll help to lay the full foundation for it first.

Is there an answer to "the table of contents must match the spine order otherwise ..." that doesn't end with general user confusion?

Including a table of contents is only a technique for satisfying the multiple ways requirement in WCAG. While they say to check that the order is sequential in the technique, I doubt they were considering all the possible publishing cases in suggesting that, as it is only even possible for a single-page document (i.e., what is order when you have a multi-page web site?).

[avneeshsingh]

It looks that we are mixing many issues here.

• Multiple TOC will be helpful. It will help in navigating through connected topics in the book.
• Constraints placed by spine is an issue related to EPUB specifications, and not an issue specific to EPUB Accessibility specifications. EPUB accessibility applies extra constraints on EPUB specifications for ensuring accessibility.

The main concern behind out of order TOC is unpredictability. People with disabilities rely a lot on predictability. It will be confusing if TOC entry after chapter 6 takes you to chapter 2, and even worse if it takes you to a subsection sitting deep in chapter 2. One will be completely lost in such a situation.

I like the idea of multiple TOC, but we need to have a way of alerting the user that TOC is in order or out of order.

[murata2makoto]

@Doktorchen IMHO, EPUB is for mimicking printed and paged books. When an authoritative reading order does not exist, I would not use EPUB.

[murata2makoto]

@shiestyle We are not talking about conformance to EPUB 3. We are talking about conformance to EPUB Accessibility. Just like some HTML documents do not conform to WCAG, some EPUB publications will not conform to EPUB Accessibility. This is inevitable. What is wrong?

[Doktorchen]

avneeshsingh - if you have multiple alternative chapters 3 (a, b, c, d ...) after chapter 2 in a fiction book, there is simply no order for all those chapters 3. And one of the chapters 4, beeing an alternative next chapter of chapter 3c, is typically not related concerning order to another chapter 4, that is a next chapter of chapter 3a. Usually such books have a subnavigation at the end of a chapter to select between meaningful alternatives, depending on a decision of the reader, therefore the individual reading order is created by the reader with such decisions.

If one has a book with a selection between variants in different languages, all those chapters N in different languages do not have a direct relation order to chapters O or M in another language. There is no preferred reading order for the different language versions, because this depends on the capabilities of each individual reader.

If you have the example with the tour book about Paris, it depends on the interests of the reader to get a meaningful reading order.

If one has an educational book about different fields of atomic physics, how should authors know, about which field a PhD candidate needs to learn something for his application. And while reading, how to know, which key word in a chapters results in further needs to learn something? About dye lasers, atomic beamc techniques, detection of ions, digital counting of particles, ...? A meaningful reading order is determined by the individual reader, not the authors, this is characteristic for collections about a wider research area. Usually people do not have to read the complete book, because several things they already know, others are not of much relevance for their own intentions. For some areas they may learn while reading, that they want to know more about it.

In many types of books, there is no reading order, if printed, the selected order is often arbitrary, for example in an encyclopedia - the way of wikipedia is far more efficient than that of classical printed encyclopedias. If represented in an EPUB, one will follow the wikipedia method instead of that of printed books.

murata2makoto: I never found a strong relation between EPUB and printed books. This applies for PDF or postscript, if you need to simulate printed books, such formats a much mor efficient for that purpose, you should not use EPUB for such an application. EPUB is a good recommendation for text and graphics content, that belongs together, typically without such artificial page disposition. On the contrary, paged disposition often disrupt the reading experience in printed books or presentations simulating this, in most cases paged presentation is annoying, except for usual graphics, but there are some presentation programs for EPUB, that fragment even a single graphic into multiple pages - such programs are completely useless for the audience.

Each time, some presentation program tries to simulate a printed book appearence for an EPUB, this caueses accessibility problems for readers for many books, this is an annoying thing, but not a feature of EPUB itself. It is more a structured archive for content comparable to what you find in the web, but because XML is used instead of tag soup, content has to be accessible without scripting, with switched off author styling, readers should have less accessibility problems as for content in the web, that meanwhile often or usueally have such problems.

[murata2makoto]

@Doktorchen

Although I agree that pages are not central to EPUB, I do think that a single authoritative linear order is very central to EPUB. If some publication does not have such an order, I would not use EPUB.

[avneeshsingh]

@Doktorchen , we are going little off topic here. If requirement of spine in EPUB 3 or predefined reading order is a problem, then it would be good to open a separate issue for it. This issue is specific to EPUB accessibility, and our objective is to determine if we want to have additional constraints or guidance over and above EPUB 3 specifications.

[mattgarrish]

It will be confusing if TOC entry after chapter 6 takes you to chapter 2, and even worse if it takes you to a subsection sitting deep in chapter 2.

Right, but this problem exists for all users, so I'm not sure a new success criterion is the best approach. My thinking is that there should be a clear path to making any success criterion a WCAG criterion, even if we don't immediately pursue that option.

I wonder if it's something we should try to explain in the techniques so that there is at least some flexibility if legitimate cases come up that don't negatively affect accessibility.

In other words, maybe we need to expand on the WCAG table of content technique to explain that it is a requirement that the toc match the linear order of the spine for works that have a sequential reading experience, but that some exceptions may be made for content that can be read non-linearly so long as the table of contents still makes logical sense for the work.

It would also be a more fitting place to mention other options, like alternative navigation or why some books might have a limited toc (choose your own adventures) and still be accessible.

[Doktorchen]

Additional recommendations or requirements here can result in confusion for authors of such non linear books, resulting in workarounds to avoid epubcheck warnings or warnings from other checkers, with the result of less accessibility for the audience. Typically, if warnings do not apply, they result in creative 'solutions', resulting often in even worse problems for the audience. The limitations of paged printed books provide examples for this over centuries. In my PhD thesis (in these days LaTex with postscript or PDF output) I had to rearrange graphics, text around to get it into these page limitations, this results in suboptimal, sometimes mad structures. I switched to (X)HTML to get rid of such issues, both annoying for authors and readers.

If authors could organise the spine element properly or setting a flag, that a simple book has only one meaningful reading order, of course, for such books it has some use, to check, that this order is realised within the book, for other books it would be misleading. Therefore a flag would be required to indicate, that a linear reading order has some meaning for an individual book. If authors cannot indicate this, it will be difficult to provide a general guidance for books as well, that have a more complex content structure.

murata2makoto: EPUB spine element provides already a feature, that some content is not linear. EPUB contains XHTML, SVG, Therfore such books are covered pretty good by EPUB, you should use this standard format for such books.

But the indication within the spine element, that some documents are not linear can be already some kind of minimalistic solution for an accessibility guidance or check of a linear order: Both applies only for content, that is explicitly indicated to be linear. Everything else is out of scope for such hints. Because currently EPUB does not provide guidance, how to structure a navigation document or subnavigations for such non linear content, one has to accept, that such linear content can appear in any order, even repeated within such a list of content.

I think, it is not a good idea to exclude a major fraction of digital books from EPUB, advanced concepts, how to arrange content or how to learn something, just because printed books cannot represent such concepts in a proper way. Digital books, EPUB goes beyond such restrictions of arranging glyphs on sheets of paper. If authors provide proper subnavigations within nonlinear content documents, there is no accessibility problem, just because the audience has to select from a list, what they want to read next.

[murata2makoto]

@Doktorchen We can probably agree to disagree. I think that EPUB is a miniature garden for mimicking traditional linearly-ordered printed books and that the OWP should be used for more advanced digital publications. Some minor features of non-linearity in EPUB exist but they do not make EPUB truly appropriate for totally non-linear publications.

[Doktorchen]

OWP? Hmmm, I cannot see a relation, they produce for example spectacles, but no digital books. https://www.owp.de Or Offshore-wind-parks? How they are related to non linear books? ;o)

[murata2makoto]

@Doktorchen

OWP = Open Web Platform

[Doktorchen]

The content seems to be similar to that of EPUB. If it has a recommendation and an archive type for static, book like content it could replace EPUB, but why to have two formats for the same purpose?

Concerning acessibility, does it really help to split into different formats. Isn't it even worse enough to have the propriatery amazon formats in addition to EPUB, why yet another open format?

But if this is only a buzzword for the usual collection of formats, maybe they simply can add EPUB for digital books to buzz a little bit more ;o)

[iherman]

The issue was discussed in a meeting on 2020-12-10)

List of resolutions:

• Resolution No. 1: We are not having success criteria of aligning nav doc with spine, but we will have a technique for it..

View the transcript

### 1. Alignment of NAV TOC with spine _See github issue [#1430](https://github.com/w3c/epub-specs/issues/1430)._ **Avneesh Singh:** alignment is no longer a requirement in EPUB spec 3.3. … however, it is recommended. … should alignment be added as requirement in a11y?. > *Matthew Chan:* .. after discussion in github, it seems we should not make this a requirement. **Avneesh Singh:** maybe we can just add a warning at the toc is out of order?. **Charles LaPierre:** agreed. There are cases were TOC will not be in complete alignment. … when this is the case, the technique document should say to add this warning to the accessibility summary. **Avneesh Singh:** the technique should recommend that TOC should align with spine, unless there is a real need for it to not align. … and that there should be text in the TOC that conveys that the toc is out of order. … and a note in the accessibility summary. **George Kerscher:** how would adding a note to the nav TOC work?. … I would think that somewhere in the book, in the beginning, the presence of multiple TOCs would be explained. … like an explanation of how to use the book. … maybe this could be a best practice that we promote?. … and the accessibility summary would say, "this book is not meant to be read linearly, and there is text that explains how best to explore this book". **Avneesh Singh:** We can have the discussion about technique on a separate call. We'll give this proposal to Matt G, and he'll come back with the technique. **Charles LaPierre:** also, should we add something to the epub that exposes that sort of disclaimer text to the user as well?. … but then RS will have to implement that. **Avneesh Singh:** There could be a text in the TOC element itself, but this text wouldn't necessarily be displayed by RS where the TOC appears visually like an expandable tree. > **Proposed resolution: We are not having success criteria of aligning nav doc with spine, but we will have a technique for it..** *(Avneesh Singh)* > *Matthew Chan:* +1. > *Laura Brady:* +1. > *Charles LaPierre:* +1. > *Juliette McShane:* +1. > *Ben Schroeter:* +1. > *Bill Kasdorf:* +1. > *George Kerscher:* +1. > ***Resolution #1: We are not having success criteria of aligning nav doc with spine, but we will have a technique for it..*** **Avneesh Singh:** I will discuss this will Dave and Wendy. Will open an issue about maybe having a flag to indicate lack of alignment. > *Jun’Ichi Yoshii:* +1.