Do all documents in the reading order have to be reachable from the ToC #39
Comments
|
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):
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). |
|
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. |
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.
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.
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). |
rdeltour
changed the title
|
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. |
|
@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:
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:
|
|
In reply to @clapierre
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
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.
Yeah, just
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).
👍 |
|
Your whole promise here, Romain, is based on an incorrect expectation -
that all web publications (WP) *must* comply with WCAG. That is *not true*!
Instead, we have agreed that we will ensure that any author wishing to
create an accessible WP can do so (aka no blockers).
Therefore our compliance or lack thereof has no bearing *as long as* we
enable someone to comply. And I don't see us doing anything with any
proposal so far that would block...
…On Fri, Aug 18, 2017 at 5:06 AM, Romain Deltour ***@***.***> wrote:
There is a consensus that a Web publication must have a *reading order*
(a list of primary resources) and must/should have a *table of contents
(ToC)* (the main navigation entry point).
Scope
The goal of this issue is to debate whether the spec should strive to
enforce or recommend that *all* the primary resources should be reachable
from the ToC, or not. This is about conceptual relationship between the ToC
and reading order, notably with accessibility in mind.
In other words, the objective is to provide answers to the following
questions (the list can be edited as the discussion goes on):
1. are there legitimate use cases where a primary resource would not
be listed in the ToC
2. a primary resource is not listed in the ToC, does it violate WCAG
SC 2.4.5 <https://www.w3.org/TR/WCAG20/#navigation-mechanisms-mult-loc>
3. if not, and if the ToC is incomplete, is the list of primary
resource equivalent of a "site map" (i.e. does it satisfy WCAG
technique G63 <https://www.w3.org/TR/WCAG20-TECHS/G63>?
4. ultimately, how does that translate into the spec (must, should,
note, etc.)
Out of scope
This issue is *not* about discussing:
- the format details
- how to infer one structure from another (as in issue #36
<#36>)
As @baldurbjarnason pointed out
<#36 (comment)>:
we need to start off by specifying a format that supports these as
independent structures before we specify how you'd use one type of
structure to generate another. And we should be explicit in the
specification that these conversions can fail for a variety of reasons.
References
- Issue #38 <#38> "What does
“Reading Order” mean"
- Issue #36 <#36> "Is the ToC
sufficient to provide reading order?"
- Issue #26 <#26> "Should the
manifest be an implicit ToC?"
- WCAG SC 2.4.5 "Multiple ways"
<https://www.w3.org/TR/WCAG20/#navigation-mechanisms-mult-loc>
- Understanding WCAG SC 2.4.5
<https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-mult-loc.html>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#39>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AE1vNed0E3ycXEq0b_3iM0nnIrxye4e8ks5sZVQsgaJpZM4O7SmG>
.
|
|
@lrosenthol I understood that accessibility was in WP scope.
|
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.
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. |
|
On Fri, Aug 18, 2017 at 10:45 AM, laudrain ***@***.***> wrote:
@lrosenthol <https://github.com/lrosenthol> I understood that
accessibility was in WP scope.
Ensuring that WPs can be made accessible - absolutely! Are mandated to
be, no. Big difference.
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.
Correct. That says right there that we will ensure that WP's can be
accessible to such readers. It does not imply that every single WP will be
accessible.
Profiles of Web Publications may be defined with more stringent
accessibility requirements
And there is the followup that says it more specifically. That some
profiles (let's say EPUB4) will be even more stringent in their
requirements.
|
|
On Fri, Aug 18, 2017 at 10:47 AM, Romain Deltour ***@***.***> wrote:
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.
Glad to hear we are on the same page then, and sorry for implying otherwise.
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.
I agree completely with that as well.
|
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"). |
|
I find that the accessibility guidelines cover this quite nicely themselves:
The key here is the "process" bit which links to:
SidebarWhat 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:
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. |
|
In addition to the now usual 👍 on @baldurbjarnason, let me just a couple comments:
Fully agree. I think we can add that to our design principles.
One big issue however is duplication of content. EPUB is often despised for having lots of duplication in |
|
OK, so let me propose a conclusion on this issue:
|
|
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 😊 |
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). |
|
@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? |
|
@rdeltour |
|
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. |
|
@rdeltour and also @BigBlueHat
EPUB has a lot of duplication that could be avoided, for example the requirement to declare all resources in But we're talking about completely different concepts here:
Let me be more explicit about that last point:
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:
@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. |
|
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). |
TzviyaSiegman
modified the milestones:
Manifest Serialization,
Identifying secondary resources,
Manifest Serialization/Concrete Manifest
|
Just to complement the |
|
Propose closing: The current draft makes a difference between resource list and toc. The issue seems to be covered... |
edited to better describe the scope
There is a consensus that a Web publication must have a reading order (a list of primary resources) and must/should have a table of contents (ToC) (the main navigation entry point).
Scope
The goal of this issue is to debate whether accessibility best practices require that all the primary resources should be reachable from the ToC, or not. This is about conceptual relationship between the ToC and reading order.
In other words, the objective is to provide answers to the following questions (the list can be edited as the discussion goes on):
Out of scope
This issue is not about discussing:
As @baldurbjarnason pointed out:
References
The text was updated successfully, but these errors were encountered: