Re: Looking for some clarification

Hi John,

Matt, Tzviya and Charles have already provided good responses.
Regarding your question about terms like frontmatter, bodymatter, rearmatter, etc, these came from DAISY NISO Z39.86 specifications, released in 2005. The original set of semantics came from ISO, but I do not remember the two decades old ISO specifications, George and Marku are the only active people who worked on these 20 to 25 years ago! These terms are being used for many many years now.

Under IDPF, a set of semantics went into epub:type, and then a subset went into DPUB aria roles.
In the current situation DPUB aria roles are used for accessibility, while epub:type is mostly used in production systems, and also in a few reading systems.

It is a good question why we are living in a ambiguous state of DPUB aria and epub:type. The answer is that changes happen very slowly in the publishing industry. We cannot afford to break existing systems. It is very different from web industry where the web developers embrace the changes quickly. On the other hand the decision of updating publisher’s production systems comes with a lot of overheads. An unrelated example: we avoid frequent updates of EPUBCheck also, to avoid publisher’s overhead of integrating the updated version of the tool in their workflows.

With regards
Avneesh

From: Matt Garrish 
Sent: Friday, July 30, 2021 4:46
To: 'John Foliot' 
Cc: 'Charles LaPierre' ; 'W3C EPUB 3 Working Group' ; 'Avneesh Singh' ; 'Ivan Herman' 
Subject: RE: Looking for some clarification

> my only point of reference was HTML Landmark elements / ARIA landmark roles (i.e. <nav> / role="navigation"), which serve a use for screen reader users at the HTML page level

 

Right, and this is why you won’t find “doc-landmarks” in the DPUB-ARIA module, as it is way too confusing and prone to misinterpretation when explained alongside ARIA landmarks. (I think we had it in the original proposal as a possible means of killing off epub:type in the navigation document, but the ARIA group balked at it and we never could find an alternative. There was probably a bit of hope on our part that an EPUB 4 wouldn’t be far off in which landmarks could be completely re-evaluated.)

 

EPUB 3’s landmarks nav is also confusing with guides in the EPUB 2’s NCX file, as it isn’t meant to be a sort of tour of content.

 

My mind tends to get fried by this point in a revision, but I’m now remembering we had a conversation about this earlier on and came to a sort of compromise of complete optionality to deal with what Thorium does. The reading systems specification now says about the nav that it “MAY provide users access to the links in the landmarks nav element [EPUB-33] and MAY use the links to enable functionality in the application”.

 

The root problem is that we started off the life of EPUB 3 without any fully working implementations (only a spec and a dream!), so things we expected would evolve over time didn’t always. Moving EPUB 3 to a W3C REC is exposing a number of these lesser-implemented features. I’d love to say let’s also deprecate this and try to figure it out in another major revision, but unfortunately that’s not likely possible. We’re constrained to not invalidating existing EPUB content (causes major distribution headaches for publishers if there are errors or even warnings), and landmarks are widely authored if not widely used. The landmarks probably also would pass W3C’s two implementation requirement, since there are multiple reading systems making use of them, if not in consistent ways.

 

But I hate that we only sort of shrug and tell people to include what they like or think has use. If nothing else, we should be making clear that it’s not another table of contents, but what constitutes “important” landmarks is also going to be hard to pin down. Personally, I see the most value in the landmarks nav if it is limited to major reference sections, like lists of tables/examples/illustrations, indexes, bibliographies, and glossaries, plus the major document partitions (front, body and back matter). Even if we can’t limit it to those, some guidance in that direction would improve understanding.

 

But I’ll open an issue for this in github, as that’s probably a better place to carry out a discussion.

 

Matt

 

From: John Foliot <john@foliot.ca> 
Sent: July 29, 2021 5:52 PM
To: Matt Garrish <matt.garrish@gmail.com>
Cc: John Foliot <john@foliot.ca>; Charles LaPierre <charlesl@benetech.org>; W3C EPUB 3 Working Group <public-epub-wg@w3.org>; Avneesh Singh <avneesh.sg@gmail.com>; Ivan Herman <ivan@w3.org>
Subject: Re: Looking for some clarification

 

Hi Matt,

 

I don't want to argue (LOL), I'm trying to learn / catch up, and so with me you have a Standards wonk who's worked in web accessibility for 20+ years (and more than 15 years directly within the W3C) asking newbie questions - is all.

 

I tend to agree with your overall assessment: I too was trying to grok what the 'landmarks' were doing, and/but my only point of reference was HTML Landmark elements / ARIA landmark roles (i.e. <nav> / role="navigation"), which serve a use for screen reader users at the HTML page level (inter-page navigation). In that use-case, from an accessibility perspective I've always suggested that *at a minimum* an HTML document has (inside the <body> element) <nav>, <main>, and <footer>; everything else is gravy.

But EPUBs are a different kind of beast, and it was both useful and insightful to me to learn that the <nav> landmarks in epub (epub:type) were originally intended for a slightly different reason, and I guess it's kind of sad that their intended functionality is not being taken advantage of at the level you had hoped.

 

With regard to your comment about Thorium, I agree that here, WCAG SC 2.4.4 would indeed come into play *when* (or here, because) that link-text is being exposed directly to the end user, but as you note that is probably not a universal (nor expected per the EPUB Spec) outcome. I can help my client address that issue in their publishing system, but it does point out a bit of a... erm... gap? 

 

In fact, you are correct, this rightly remains with WCAG, as it seems to me to be primarily an editorial issue, and while I'd never want the EPUB spec to attempt to define "human readable", it *MAY* be appropriate to note that the terms related to Document Partitions (frontmatter, bodymatter, backmatter) - or, in fact any of the landmark values - SHOULD have more 'human-friendly' link values (mindful of i18n concerns, I'd not go further than that: perhaps some examples using multiple languages would be useful in the spec?) - which is NOT a specific WCAG SC per-se, but is certainly an overarching intent of WCAG.

 

> ...given that reading systems aren’t consistently using the links for their UI or exposing them, what do we think their function is? We’ve effectively ignored them for a long time because of the lack of uptake.

 

Finally, I find it interesting that you are contemplating revisiting the whole landmarks (via epub:type) concept - would one option there be to deprecate the whole "shootin' match" as an idea overcome by time, or not being adopted as designed? I'll watch for any thread that heads in that direction.

 

JF

 

On Thu, Jul 29, 2021 at 3:06 PM Matt Garrish <matt.garrish@gmail.com> wrote:

  If you want to argue that Thorium makes a case for human-readable labels (which is fine with me), couldn’t you also argue that this already falls under the requirement of 2.4.4 Link Purpose (In Context)? In which case, it would be covered by the accessibility specification requirements.

   

  I don’t expect we’d want to try and define “human readable” or require a AAA success criterion in the core spec, but you could point out what you think is potential jargon when assessing content for accessibility.

   

  At any rate, we may want to start back at fundamentals and better figure out why the landmarks exist. It shouldn’t be to duplicate the table of contents, and given that reading systems aren’t consistently using the links for their UI or exposing them, what do we think their function is? We’ve effectively ignored them for a long time because of the lack of uptake.

   

  Matt

   

  From: John Foliot <john@foliot.ca> 
  Sent: July 29, 2021 3:09 PM
  To: Charles LaPierre <charlesl@benetech.org>
  Cc: John Foliot <john@foliot.ca>; W3C EPUB 3 Working Group <public-epub-wg@w3.org>; Avneesh Singh <avneesh.sg@gmail.com>; Ivan Herman <ivan@w3.org>; Matt Garrish <matt.garrish@gmail.com>
  Subject: 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) 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 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 and Document Sections and Components, 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? )

        a.. Looking specifically at usage in <nav epub:type="landmarks">, is there a minimum set or collection of landmark-values expected in a publication? 
          a.. if yes, what are they? 
          b.. if no, should there be? (why/why not?)
        a.. Additionally, from an accessibility perspective, while the Rec is currently silent on this specific scenario, based on the following supplied code example 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 (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" on the surface - it's clearly not a common term in regular public usage AFAIK. Ditto "backmatter".) (@Avneesh?)

        a.. 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?)

      -- 

      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"




 

-- 

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"