Do all documents in the reading order have to be reachable from the ToC about wpub HOT 26 CLOSED

I do not think that all documents have to be accessible from the ToC. There are a number of examples in current EPUB books where this is the case you have a ToC which just brings you to the beginning of each chapter not to every single page within that chapter which may be separate xhtml pages within the EPUB. There are other ways to get to each page, ,, and then a separate GoTo Page covers the multiple ways. I think that a Reading System could generate a "site map" from the list of primary resources and possibly even secondary if we so desire.
I agree there must be some way to specify which page follows the current page and vice versa which is the "default Reading Order" but this must be overridable in the case where there could be random access to different pages based on what the user wants to do.
As long as we don't prevent random access to the content I am confident we will meet the WCAG guidelines on multiple ways to reach the content.

from wpub.

from wpub.

@rdeltour do you consider that a title/label for each primary resource is enough to support this requirement?

IMO, it's pretty much the same info, just two different ways to present it:

• as part of the reading experience (when I press next, tap or swipe I get to the next resource in the reading order)
• presented as a list (which is not something that a UA would usually do, but maybe specialized UA have this feature)

I also see that you've changed the title of this issue. In most EPUB that I've seen, the TOC doesn't cover 100% of the primary resources.

For instance it's very common to have a link to the title page in the TOC, but no link to the cover itself. Preliminary resources are often skipped, same for a number of resources at the end of the publication.

It's also fairly common to break long chapters/parts into multiple HTML files without referencing each and every one of them in the TOC.

In the case of HTML resources, this means that for each primary resource we could:

• have a title for it in the manifest
• fallback to the <title> element of each HTML resource

from wpub.

I find that the accessibility guidelines cover this quite nicely themselves:

2.4.5 Multiple Ways: More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process. (Level AA)

The key here is the "process" bit which links to:

process
series of user actions where each action is required in order to complete an activity

Example 1: Successful use of a series of Web pages on a shopping site requires users to view alternative products, prices and offers, select products, submit an order, provide shipping information and provide payment information.

Example 2: An account registration page requires successful completion of a Turing test before the registration form can be accessed.

Sidebar

What these guidelines call 'process' (Example 1, specifically) are a major idiomatic feature of how the web works. Namely, dynamic processes that diverge from the user's starting point and lead them to a new place that is a direct consequence of their actions is one of the biggest creative features of the web that publication formats so far have not supported.

(Like, I've literally had several projects of mine in the past cancelled because ePub does not support this and the potential revenue wasn't big enough for an app. And, yes, I'm bitter about it.)

This ties into my earlier points about the importance of supporting existing web forms: they all rely on this basic structural feature. And thankfully, the accessibility guidelines make allowances for it.

Given that every web publication is also a website, we need to at least give authors the same allowances as the accessibility guidelines. The reading order, when given, is only the default and dynamic processes will let the reader deviate from that course. The reading order itself is also a possible example of a dynamic process as defined in the passage I quoted above. The explanatory note for SC 2.4.5 (Multiple Ways: Understanding SC 2.4.5) mentions search, sitemaps and multiple other ways of fulfilling the multiple ways criteria. If we require authors to fulfil the multiple ways criteria in a single way, we are pre-emptively excluding a bunch of forms and genres of web publications—some of which might not exist yet—from being supported by the format.

We know that web publications won't all conform to the same structure and we can't in advance know all of the structures that publications might possibly use. Which means we have to give authors the tools to make their work accessible rather than pre-emptively limit what their work can do. Adding strictures beyond the guidelines instead could compromise their work's user experience and might even be a major roadblock for future innovation.

So, rather than making the format more limited we should build in the ability for authors to supplement the publication's navigation.

E.g. links to:

• Additional site maps.
• A page that lists all of the HTML pages (secondary or primary), non-HTML primary resources, and possibly even important external pages that are likely to be found as links in the primary resources.
• Publication-specific search facilities (e.g. OpenSearch)

Of course, publications where all of the pages are listed in the ToC won't have to do any of this (they already fulfil the multiple ways criteria) but even some of those (especially publications with really complex ToCs) might opt to supplement the ToC with search, page lists, or site maps in order to provide a better experience.

Basically, ToC, site map, list of pages, list of resources, and default reading order are all distinct structures each with their own purpose and value. I think we're going to need to support them all in some form, possibly in the form of a list of links/landmarks, which would be its own structure.

And as @rdeltour noted at the start, this is irrespective of whether we document ways for inferring one structure from another.

from wpub.

from wpub.

from wpub.

OK, so let me propose a conclusion on this issue:

• the spec cannot mandate that the ToC contains links to all the primary resources
• if the ToC contains links to all primary resources, then it is one "way" closer in fulfilling SC 2.4.5
• at some point, we may want to look at possibilities to point to a "sitemap" document from the manifest (in a similar way as we could point to a ToC with rel="contents"
• a structure defined in a external JSON manifest can't be used as-is to claim support for a WCAG SC in non-WP-aware UAs.

from wpub.

@rdeltour
I was merely referring to the possibility of providing some variation of this feature from Techniques for WCAG 2.0. And like I said, I'm not set on it, just openly wondering whether it'd be worth looking into in the future.

from wpub.

Consensus for accessibility issues should happen in the accessibility task force call, because all the members of accessibility task force are not so fluent with GitHub issue tracker.
So, we should propose this for agenda of August 23 con call.

from wpub.

@rdeltour and also @BigBlueHat

One big issue however is duplication of content. EPUB is often despised for having lots of duplication in nav/spine/manifest, and I'm starting to worry about reproducing some of the same issues here.

EPUB has a lot of duplication that could be avoided, for example the requirement to declare all resources in manifest (id) and then in the spine (idref).

But we're talking about completely different concepts here:

• a list of primary resources should not contain any secondary resources
• a TOC is pretty much whatever you want

Let me be more explicit about that last point:

• a TOC can point to primary or secondary resources
• it can list the same resource more than once
• it can point to a fragment of a resource instead of the resource itself
• it can point to resources in whatever order makes sense
• it can have a hierarchy (vs flat list for primary/secondary)
• it doesn't have to reference all primary or secondary resources

Basically, it's a completely different beast with vastly different use cases and very few requirements (if any).

For the other suggested navigation methods (search, page list, landmarks, whatever) we'll have to consider all the following options for each and every one of them:

• discovering the service at a manifest level (using rel + media type + URI template), this could work very well for search
• indicating that an HTML resource has specific info (using a rel value)
• embedding such info in the manifest itself

@baldurbjarnason has made some insightful comments about JSON vs HTML in that regard in a recent comment, that we can also use as a basis for such decisions in the future.

from wpub.

Coming late to this party, I would only add that we not be dogmatic about 2.0 wording. It has a focus on web pages and web sites, not on publications.

As the table of contents technique explains, the user wants access to the major sections of a publication, not to every resource. It is even more useful when they have access to the entire outline, but that is not a requirement.

A site map satisfies multiple ways, but even its technique doesn't require the map to list every single document.

The primary satisfier of 2.4.5 for publications is that there needs to be a way to follow the logical reading sequence of the content, whether the user choose the same path as the default reading order or not. This can be achieved through links and/or the default reading order and/or other mechanisms. The key is that the method has to be accessibility supported.

After that, techniques that satisfy the requirement should be practical for publications, and the author should have flexibility. If there are conflicts between the reality of publications and the WCAG descriptions, these are issues we should raise for the Silver release.

An index is another example of a publication feature that satisfies multiple ways but is not explicitly called out by WCAG (it's analogous to a site map, which is a web-way of looking at an index).

from wpub.

In issue #36, @HadrienGardeur proposed an example where the has 6 different primary resources but the fallback TOC could consist of only three entries.

I pointed that this could be a violation of WCAG SC 2.4.5 "Multiple ways".

Applied to Web publications, SC 2.4.5 requires that there are more than one way to locate a primary resource with a Web publication.

It means that two or more of the following techniques should be available (see Understanding SC 2.4.5):

• next/previous links (technique G125)
• a table of contents (technique G64)
• an index of all the pages ("site map") (technique G63)
• a search function (technique G161)

So absent a search function and next/previous links, my understanding is that Hadrien’s use case would be effectively violating SC 2.4.5.

My take is that the reading order list could constitute an index of all the pages. The manifest would need to provide a way to associate labels to these resources (possibly falling back to the documents titles).

from wpub.

My initial example was meant to illustrate that a primary listing reading order could be a fallback for a TOC, but I can find better example for this specific issue.

Let's take a graphic novel where each page is a bitmap image. A TOC would not provide a link to each and every page, it might point to specific chapters or sections from that graphic novels instead (and for many graphic novels, you won't find a TOC at all).

Among the techniques that you've listed, search could be tied to the UA instead of a publication. For such a graphic novel though, I'm not sure that search would be helpful or even work at all.

from wpub.

My initial example was meant to illustrate that a primary listing reading order could be a fallback for a TOC

Understood 👍. As said in the issue's description, the the question of fallbacks and inferring one from the other is quite orthogonal to this issue, and very much depends on the formats details anyway.

Let's take a graphic novel where each page is a bitmap image.

Interesting example. A graphic novel is quite a different beast, and a very challenging one for accessibility. In the context of accessibility, I think we can focus at first on publications made of HTML documents only.

Among the techniques that you've listed, search could be tied to the UA instead of a publication.

Indeed. I'm not sure exactly how to deal with that in a11y guidelines. The idea IMO is that –when looking at 2.4.5 at least–, the publication should intrinsically fulfill the SC (i.e. without depending on UA-provided features).

from wpub.

There's lots of mentions here (in #35 and #36) of books that don't currently include all their primary resources in their Table of Contents documents.

Is there any reason they SHOULD or MUST not reference them?

from wpub.

In reply to @clapierre

There are a number of examples in current EPUB books where this is the case you have a ToC which just brings you to the beginning of each chapter not to every single page within that chapter which may be separate xhtml pages within the EPUB.

right, I know. but I'm not convinced that this practice (which mostly stems from legacy RS limitations with dealing with large files) actually makes sense in a Web pub.

In reply to @HadrienGardeur

do you consider that a title/label for each primary resource is enough to support this requirement?

Yes, I think so. I'm not sure to which extent information contained in an external JSON manifest can be considered as satisfying WCAG, but that's a separate (albeit related) larger issue.

I also see that you've changed the title of this issue.

Yeah, just s/accessible/reachable/ to avoid confusion with "accessibility".

It's also fairly common to break long chapters/parts into multiple HTML

As said in reply to @clapierre above, I'm not sure this practice would stay true in Web pubs (of course, we can't mandate anything about that).

In the case of HTML resources, this means that for each primary resource we could:

• have a title for it in the manifest
• fallback to the <title> element of each HTML resource

👍

from wpub.

@lrosenthol I understood that accessibility was in WP scope.
See our charter:

Recommendation-track deliverables will contain mechanisms to make Web Publications accessible to a broad range of readers with different needs and capabilities. This includes general Web Content Accessibility Guidelines (WCAG) and Web Accessiblity Initiative (WAI) requirements of the W3C as well as requirements for international readers using different scripts and document formats. Profiles of Web Publications may be defined with more stringent accessibility requirements.

from wpub.

Your whole promise here, Romain, is based on an incorrect expectation -
that all web publications (WP) must comply with WCAG.

No. I'm just asking questions, and explicitly said that whether it's a must, a should, a note, or even be left to a best practice document, is open for debate.

I personally don't believe that the spec should say that all WP must comply with WCAG.

This issue is to debate the conceptual relationship between ToC and reading orders, and the role these structures (or lack thereof) can play in satisfying accessibility guidelines.

Therefore our compliance or lack thereof has no bearing as long as we
enable someone to comply.

I for one, would very much like to avoid, for newly specified formats like a JSON manifest, to open avenues that will make inaccessibility easy and accessibility difficult.

from wpub.

Glad to hear we are on the same page then, and sorry for implying otherwise.

No worries 😉! I reworded the scope in the OP to make it more explicit (replaced "whether the spec should strive to enforce that" by "whether accessibility best practices requires that").

from wpub.

In addition to the now usual 👍 on @baldurbjarnason, let me just a couple comments:

If we require authors to fulfil the multiple ways criteria in a single way, we are pre-emptively excluding a bunch of forms and genres of web publications

Fully agree. I think we can add that to our design principles.

ToC, site map, list of pages, list of resources, and default reading order are all distinct structures each with their own purpose and value. I think we're going to need to support them all in some form

One big issue however is duplication of content. EPUB is often despised for having lots of duplication in nav/spine/manifest, and I'm starting to worry about reproducing some of the same issues here.
In addition, the fact that any structure defined in a JSON manifest can't be used as a technique to satisfy a WCAG criteria, at least on legacy UAs and without a script that would render them as HTML, probably makes the duplication problem unavoidable in most cases.

from wpub.

@rdeltour

That looks fine to me. I'd also like to add the possibility of letting people also point to a 'page list' document that's a flat list of all pages. That can also be advantageous under circumstances where complex hierarchical documents may be less accessible or too hard to use. Just as a thing to possibly investigate. I won't be heartbroken if the idea gets left out 😊

from wpub.

I'd also like to add the possibility of letting people also point to a 'page list' document that's a flat list of all pages

I'm not sure I see how that needs to be different to a "sitemap", especially in the contest of WP. A "sitemap" is quite a loosely defined concept, you could fairly well include both a graph-like view for fancy hypertext publication and a flat list.

Also, there's a minor terminology issue: "page list" is used in EPUB and DPUB ARIA to refer to the list of page breaks (or rather, their position in the equivalent statically paginated version, like a print book).

from wpub.

@rdeltour I am fine with this conclusion; my question is more operational. We should not close the issue because it may be lost. On the other hand, it is to early to put this into the FPWD editor's draft, there is not real place for this.

The accesibility task force has its separate repository now, asked by @avneeshsingh. Maybe there should be a separate discussion that would document the accessibiltiy related issues and conclusions (or a refernece to the relevant and concluded issues) so that we could pick them up later to incorporate them into the evolving document when the time comes. WDYT?

from wpub.

Just to complement the topic:accessibility label, here is a link to the wiki page (draft) where requirements are being gathered:
https://github.com/w3c/publ-a11y/wiki/Description-of-Accessibility-Requirements-for-WP#navigation-and-default-reading-order

from wpub.

Propose closing: The current draft makes a difference between resource list and toc. The issue seems to be covered...

from wpub.

Closing per https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-03-12-minutes.html#resolution7

from wpub.