Re: Looking for some clarification

Hi John,

One other thing to note that Thorium Reader<https://www.edrlab.org/software/thorium-reader/> does expose the list of Landmarks as shown below:


[cid:A54CD511-EA9E-474A-970F-5D262D9F1895]

[Alt: Partial Screen Shot of Thorium showing the Landmarks section of an EPUB with the following landmarks defined: Cover, Title Page, Copyright Page, About the Editors, Contributors, Preface, Contents, Start of Content, and Index]

These landmarks at taken out of the toc.xhtml file with <nav epub:type="landmarks" …>

Thanks
EOM
Charles LaPierre
Technical Lead, DIAGRAM and Born Accessible
Imageshare Product Manager
Twitter: @CLaPierreA11Y
Skype: charles_lapierre


On Jul 29, 2021, at 9:39 AM, Matt Garrish <matt.garrish@gmail.com<mailto:matt.garrish@gmail.com>> wrote:

Hi John,

> Looking specifically at usage in <nav epub:type="landmarks">, is there a minimum set or collection of landmark-values expected in a publication?

No. We’ve looked at this issue in the past, but the landmarks are for reading system use and there’s no requirement that reading systems implement any functionality based on landmarks. I believe the only behaviour that’s been documented as having some uptake is including a link with epub:type=bodymatter so that reading systems can automatically skip the front matter when opening a publication. But that’s not universal and not something we’d want to enforce now.

> I am *presuming* that the Partition value (actually, any epub:type's value) should also use a "Human Readable" label (accessible name),

It would be helpful if the links were exposed to users, yes, but the landmarks links are the more central part. The original idea was that the reading system could use these links to implement its UI (e.g., have a dedicated button to open a glossary or index), so the text of the links would most likely be discarded to provide a consistent interface. Listing all kinds of general content destinations in the landmarks for users is largely redundant with the table of contents.

> Document Partitions vs. Document Sections and Components, does one category have stronger or more important semantics in practical usage?

Front, body and back matter are conceptual divisions of a publication that overarch the content. Front matter in most English texts, for example, is demarked by roman numerals and contains title pages, tables of contents, dedications, forwards, etc.

You don’t necessarily have to pick only one semantic, in other words, as this isn’t the role attribute where only one is recognized. All of the listed semantics are applicable. This is also because the semantics (and epub:type) were designed first for publishers wanting to use the semantics in internal workflows.

They then took on a life of their own and have been used (and abused) in a variety of ways for different purposes in EPUB. Placing them on links in the landmarks is a useful hack, for example, but what does it mean that a link is the front matter and/or a forward? That the semantics describe what is at the end of the link is a creation that only exists for the landmarks, I believe.

Structuring the list of landmarks probably does nothing but further complex an underutilized feature of EPUB. You’re starting to turn it back into a table of contents. You could put two semantics on a single item if it makes sense (e.g., a forward is also your first piece of front matter), but otherwise I’d keep the list flat. I’m kind of surprised the restriction to a flat list of entries, as we have for the page list, isn’t also defined for the landmarks.

> why is the Structural Semantics Vocabulary non-normative in the Recommendation?

The appendixes are normative unless marked otherwise and I don’t see a non-normative label on the vocabulary. Where are you seeing it is informative?

Matt

From: John Foliot <john@foliot.ca<mailto:john@foliot.ca>>
Sent: July 29, 2021 12:45 PM
To: W3C EPUB 3 Working Group <public-epub-wg@w3.org<mailto:public-epub-wg@w3.org>>; Avneesh Singh <avneesh.sg@gmail.com<mailto:avneesh.sg@gmail.com>>; Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>
Subject: Looking for some clarification

Hi All,

As I continue to digest the current EPUB 3.3 Rec, I'd like to ask some specific questions (if I may) regarding Structural Semantics Vocabulary*.

Specifically, I am looking to understand the relationship/similarities/differences between Document Partitions<https://www.w3.org/TR/epub-33/#partitions> and Document Sections and Components<https://www.w3.org/TR/epub-33/#sections>, as they appear (to me) to be very similar in function. (But, for example, would/could a Section or Component be a child of a Partition? Or are they hierarchically equal? )

  *   Looking specifically at usage in <nav epub:type="landmarks">, is there a minimum set or collection of landmark-values expected in a publication?

     *   if yes, what are they?
     *   if no, should there be? (why/why not?)

  *   Additionally, from an accessibility perspective, while the Rec is currently silent on this specific scenario, based on the following supplied code example<https://www.w3.org/TR/epub-33/#example-33> I am *presuming* that the Partition value (actually, any epub:type's value) should also use a "Human Readable" label (accessible name), as seen here with the epub:type of bodymatter, where the label is Start of Content:

<nav epub:type="landmarks">
    <h2>Guide</h2>
    <ol>
        <li><a epub:type="toc" href="#toc">Table of Contents</a></li>
        <li><a epub:type="loi" href="content.html#loi">List of Illustrations</a></li>
        <li><a epub:type="bodymatter" href="content.html#bodymatter">Start of Content</a></li>
    </ol>
</nav>

I ask this, because currently I am seeing (in sample books I am reviewing) that in many instances the epub:type value is being echoed as the human-readable label as well (i.e. <a epub:type="Frontmatter" href="...">Frontmatter</a>), which my gut is cringing at, as being less than useful for some users with different forms of cognitive disability.
(It's a bit of a stretch to be sure, but WCAG SC 3.1.3 Unusual Words<https://www.w3.org/TR/WCAG21/#unusual-words> (Level AAA) states: A mechanism is available for identifying specific definitions of words or phrases used in an unusual or restricted way, including idioms and jargon. - and to *my* mind at least, Frontmatter is fairly "jargony<https://www.w3.org/TR/WCAG21/#dfn-jargon>" on the surface - it's clearly not a common term in regular public usage AFAIK. Ditto "backmatter".) (@Avneesh?)

  *   Returning to  Document Partitions vs. Document Sections and Components, does one category have stronger or more important semantics in practical usage? i.e. both Frontmatter and Forward feel very similar (synonymous?) to each other conceptually - If I had to choose just one, which would/should I choose? (and why?) Or, as I asked previously, could I/would I seek to do something like this?

<nav epub:type="landmarks">
    <h2>Guide</h2>
    <ol>
        <li><a epub:type="Frontmatter" href="content.html#frontmatter">Frontmatter</a> (* ya, yech)
            <ol>
                <li><a epub:type="Forward" href="content.html#forward">Forward</a></li>
                <li><a epub:type="Preface" href="content.html#preface">Preface</a></li>
            </ol>
        </li>
        <li><a epub:type="loi" href="content.html#loi">List of Illustrations</a></li>
        <li><a epub:type="bodymatter" href="content.html#bodymatter">Start of Content</a></li>
    </ol>
</nav>
(Or am I overthinking this?)
Thanks in advance for any insights you can provide me.

JF

(* At the risk of asking too many questions, why is the Structural Semantics Vocabulary non-normative in the Recommendation? It appears to be furnishing specific definitions to multiple value terms. As a standards wonk, it strikes me that those definitions would probably want to be normative - or, again, am I missing something here? @Ivan - has there been any discussion of moving those definitions into the proposed W3C Registry<https://github.com/w3c/w3process/pull/335>?)
--
John Foliot | Senior Industry Specialist, Digital Accessibility
"I made this so long because I did not have time to make it shorter." - Pascal "links go places, buttons do things"