Re: Looking for some clarification

Hi Charles,

Yes, and in fact it is that behavior in Thorium that led me to ask/state:


"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*:..."

Matt's response suggests (to me) that this is currently not a requirement
in the EPUB specification, that the anticipation/expectation of most
reading systems would be to use the 'link' functionality of the <nav> list
landmarks, but to 'swap-out' or replace that "Link Text" in one or more
systems with a standardized, system 'term' (presumably so that all books
would be using the same term, which isn't a bad thing at all).

I'm the new guy here, but perhaps the spec should speak more succinctly to
this however, with possibly a SHOULD statement (ref: RFC 2119
<https://www.ietf.org/rfc/rfc2119.txt>) that the 'link text' used here be
Human Readable (for those reading systems, like Thorium, that simply grab
whatever the authored value is and uses that.)

Should I file an issue in GitHub?

JF

On Thu, Jul 29, 2021 at 1:56 PM Charles LaPierre <charlesl@benetech.org>
wrote:

> 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:
>
>
>
> [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> 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>
> *Sent:* July 29, 2021 12:45 PM
> *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
>
> 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"
>
>
>

-- 
*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"