RE: Looking for some clarification

Hi John,

I’ll take a stab at this since I’ve done some work over the years. I am going to provide some historical context, and others can jump in if I’m missing details or with more accuracy. We created the Structural Semantic Vocabulary in the IDPF hoping that the terms would accomplish a lot of things. Publishing is an XML world, and we like to be very specific. People were interested in being able to label components and sub-components of their files, hence epub:type labels like “chapter” and “foreword”. I believe some terms were inherited from DAISY’s DTBook spec, but I am no expert there. We also thought it would be helpful for the reading systems to have information that could inform things about UI, especially navigation. This led to elements like “toc” and “loi” as well as “frontmatter” (a catch-all phrase for all materials that precede the main contents of the book, such as copyright page, foreword, preface, dedication). With extreme optimism, we thought this could inform AT and we encouraged people to include these terms to help with accessibility. When the IDPF explored satellite specs, several more terms were added as draft terms but not finalized.

As we began looking at shifting toward HTML and what works/doesn’t work in EPUB, we found that reading systems make use of only a handful of epub:type labels (toc, lot, loi, landmarks – which are not to be confused with ARIA landmarks – cover, and footnote(s). I may have left out one or two. However, many publishers use these terms to inform their own workflows. If we took SSV out of EPUB 3.3 we would no longer be backward compatible. We have left them in as non-normative. If we made them normative and introduced testing, most of the terms would go away. This means that there are not a lot of rules about how to use them.

The DPUB-ARIA spec [1] includes ARIA roles for what the authors of that spec and the members of the DPUB IG felt were the most important roles at the time. It is fine to use both epub:type and ARIA roles. ARIA, of course, has much stricter rules. I believe the code samples in question are not demonstrating accessibility, just how to use the SSV. Since most of the roles do not convey meaning outside of your workflow, it is up to you how to use them.

Tzviya

[1] https://www.w3.org/TR/dpub-aria-1.0/


Tzviya Siegman
Information Standards Principal
Wiley
201-748-6884
tsiegman@wiley.com<mailto:tsiegman@wiley.com>

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

⛔
This is an external email.
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://urldefense.com/v3/__https:/www.w3.org/TR/epub-33/*partitions__;Iw!!N11eV2iwtfs!4q_XlcSeL2mPSTLOyx1wGLGyUUOhl1cz4Vf6YE-HGvAWMKydfyJK_uaM8e2xsw$> and Document Sections and Components<https://urldefense.com/v3/__https:/www.w3.org/TR/epub-33/*sections__;Iw!!N11eV2iwtfs!4q_XlcSeL2mPSTLOyx1wGLGyUUOhl1cz4Vf6YE-HGvAWMKydfyJK_ubwF-kxGw$>, 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://urldefense.com/v3/__https:/www.w3.org/TR/epub-33/*example-33__;Iw!!N11eV2iwtfs!4q_XlcSeL2mPSTLOyx1wGLGyUUOhl1cz4Vf6YE-HGvAWMKydfyJK_uaevzuRKQ$> 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://urldefense.com/v3/__https:/www.w3.org/TR/WCAG21/*unusual-words__;Iw!!N11eV2iwtfs!4q_XlcSeL2mPSTLOyx1wGLGyUUOhl1cz4Vf6YE-HGvAWMKydfyJK_ubNb4A7Sg$> (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://urldefense.com/v3/__https:/www.w3.org/TR/WCAG21/*dfn-jargon__;Iw!!N11eV2iwtfs!4q_XlcSeL2mPSTLOyx1wGLGyUUOhl1cz4Vf6YE-HGvAWMKydfyJK_uZ8y18ZLg$>" 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://urldefense.com/v3/__https:/github.com/w3c/w3process/pull/335__;!!N11eV2iwtfs!4q_XlcSeL2mPSTLOyx1wGLGyUUOhl1cz4Vf6YE-HGvAWMKydfyJK_uaPUNUwoA$>?)
--
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"