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.