EPUB 3 Working Group Telco — Minutes

Date: 2021-08-27

See also the Agenda and the IRC Log

Attendees

Present: Matt Garrish, Dave Cramer, Masakazu Kitahara, Gregorio Pellegrino, Toshiaki Koike, Avneesh Singh, Wendy Reid, Matthew Chan, Deborah Kaplan, Ben Schroeter, Brady Duga, Aimee Ubbink, Jen Goulden, Dan Lazin, Tzviya Siegman, George Kerscher, Hadrien Gardeur, Murata Makoto

Regrets: Ivan Herman

Guests:

Chair: Dave Cramer

Scribe(s): Matthew Chan

Content:

Dave Cramer: are there any new people?

Aimee Ubbink: yes, hello!

Jen Goulden: Also new. I work with Aimee.

Aimee Ubbink: we’re focused on document a11y. A11y PDF specifically.
… here to contribute and learn!

Jen Goulden: I’m a braille reader. Read a lot of epub in my real life, in addition to having a professional interest!

George Kerscher: Welcome!

1. Landmarks Nav

See github issue #1761.

Dave Cramer: what is the purpose of landmark nav?

Matt Garrish: this is a continuing question. We created it originally to aid RS with hotkeys that go to specific parts of epub, stuff like that.
… but do RS even use these? And what are authors supposed to put in here?
… RS couldn’t rely on there being specific content in here
… closest thing to standard is link to start of bodymatter
… we should provide some guidance, but if this isn’t being used, then should we acknowledge that it isn’t being used? Probably can’t deprecate because some epubs already use it?

Dan Lazin: does that disagree with the explanation at the last meeting, which said that we’ve had landmark since epub2?

Matt Garrish: i think dauwhe was getting at guides, which were kind of like a tour of the content. A little different.

Dan Lazin: if this feature hasn’t been adopted widely by this point, it sounds like the sort of thing that ought to be deprecated

Brady Duga: i think tours and guides were two different things, but I hesitate to say that its not being used. It’s just being used for a specific thing: Finding the start of bodymatter.
… and its used for that purpose widely
… would be odd to deprecate it in that case

George Kerscher: screenreaders have had keys that go to landmarks, which has been useful
… i’ve heard from students when there are landmarks in each chapter that provide an overview of said chapter
… so i don’t think depreciation is appropriate, but i don’t think we need to mandate that RS have specific navigation feature for them

Dave Cramer: are these things implemented in RS based on landmark?

George Kerscher: as long as there’s a landmark in the DOM than the screenreader can go to it

Dave Cramer: we might be using “landmark” to refer to two different things?

George Kerscher: Referring to ARIA landmark here

Tzviya Siegman: right, ARIA landmarks are a different thing. And this has lead to confusion over the years
… re. difference between guide and landmark. In epub2 guide was introduced. Guide is still widely used, and relatively short: toc, begin of content, index. Something like that.
… but some books are starting to use it to duplicate toc, which makes it less useful
… i would hesitate to deprecate entirely, but maybe offer guidance to make landmark more useful

Avneesh Singh: +1 for not deprecating landmark. we should provide some guidance.

Matt Garrish: in my issue i was trying to get at this, i.e. clarifying some things about landmark. And in addition maybe say that people are mainly using it to identify start of content
… this could head people off before they get confused

Hadrien Gardeur: i think historically we have bad tendency to add more and more lists. For future versions of epub, we probably need less of these. Put some of this information in reading order, e.g. spine.

Dave Cramer: Identifying the point where people would start reading is valuable for the reader, but what is the best way to accomplish that?

Dan Lazin: my interpretation is that deprecating something already used doesn’t mean that the thing is going away immediately
… it means we’re leaving this, and there is spotty implementation

Dave Cramer: https://w3c.github.io/epub-specs/epub33/core/#deprecated

Dan Lazin: if you are new RS or author, it tells you this is not high on your list of features

Gregorio Pellegrino: another use case that I know of is being able to jump to the in-book toc
… i.e. not the nav toc

Matt Garrish: if we give some guidance on what works, we have at least a basis for starting over. Maybe say at least put toc and start of content.
… and dlazin is correct about definition of deprecation from spec perspective, but we’re also concerned about the practical implications of maybe causing books to get flagged in validation, etc.

Avneesh Singh: coming back to main principles in charter, we have backwards compat clause

Murata Makoto: +1

Avneesh Singh: i would say there is some worry about deciding to deprecate today. Safer to make more of these types of potentially breaking changes in future version of spec

Brady Duga: deprecation says this is not the recommended way of doing the thing you want to do. But this IS the way of pointing to the start of content etc.
… and it is the recommended way, in fact.
… and maybe we can return to this and set out a different way to do it in the future.
… but for now, I’m very much against deprecation

Dave Cramer: i’m with duga and avneeshsingh. I think we should follow original suggestion and clarify what this is for and what it does work for.
… not a new toc, or a completely different way of traversing the content
… maybe all that is needed for now is some editorial work
… does that seem reasonable?

Brady Duga: yes

Murata Makoto: Good to me.

Proposed resolution: Clarify the language for landmarks, close issue 1761 (Wendy Reid)

Deborah Kaplan: +1

Tzviya Siegman: +1

Dave Cramer: +1

Toshiaki Koike: +1

Brady Duga: +1

Matt Garrish: +1

Dan Lazin: +1

Avneesh Singh: +1

Gregorio Pellegrino: +1

Masakazu Kitahara: +1

Matthew Chan: +1

Murata Makoto: +1

Wendy Reid: +1

Bill Kasdorf: +1

Ben Schroeter: +1

Resolution #1: Clarify the language for landmarks, close issue 1761

2. XHTML and SVG

See github issue #1774.

Dave Cramer: apparently the SVG content doc section says RS should support searching of text, but the XHTML content doc section doesn’t mention searching
… i see the point, but I’m also concerned that in general we try to avoid describing how RS should present epub to users
… my preference is to take out the line about SVG

Matt Garrish: I don’t think we mandate certain UI features in any other point of spec. I agree on removing this. We leave this to the developers to figure out.

Tzviya Siegman: +1 to mgarrish

Matt Garrish: maybe just a note reminding RS people that SVGs can contain text

Brady Duga: fine with removing. Alternative would be to say that any text interactions that RS supports with XHTML should also be supported for SVG text. A more vague way of doing what we want.

Wendy Reid: gpellegrino which would you prefer, since it is your issue?

Gregorio Pellegrino: no position as it doesn’t strongly impact a11y. I just wanted to point out this discrepancy.

Dave Cramer: I have no objection to duga language. But probably more simple to just remove SVG bullet. Hoping that developers already know that SVG can contain text. Not sure that our reminder will change their minds about what UI feature to put in their RS.

Proposed resolution: Remove the search point from the SVG section, close issue 1774 (Wendy Reid)

Ben Schroeter: +1

Brady Duga: +1

Tzviya Siegman: +1

Deborah Kaplan: +0

Gregorio Pellegrino: +1

Toshiaki Koike: +1

Matthew Chan: +1

Wendy Reid: +1

Dan Lazin: +1

Matt Garrish: +!

Dave Cramer: +1

Masakazu Kitahara: +1

Murata Makoto: +1

Bill Kasdorf: +1

Resolution #2: Remove the search point from the SVG section, close issue 1774

3. Navigation Document Processing

See github issue #1775.

Dave Cramer: this is related to things we’ve discussed in the past. Our nav is HTML, so it can include ARIA attributes, lang, etc.
… gpellegrino proposes that we remind RS that they should honor these sorts of attributes when they present nav content in UI
… but some RS just strip everything except the text value of the stuff in nav

Hadrien Gardeur: I’m worried about this. There are very good reason why RS do that.
… if we change this RS cannot use native UI elements to present nav
… would have to be a webview
… I don’t think what is being suggested is achievable

Matt Garrish: I agree that we don’t want to go here, but for a different reason. The nav was meant to make things simple for RS. Not sure its a good idea to expand complexity at this point.

Gregorio Pellegrino: I understand the concerns. Can I amend the issue to just ask that RS adhere to lang attribute? Or to tell authors not to use those attributes in the nav, because they may not be used by RS. So author can find some way around this limitation.

Dave Cramer: i agree with Hadrien’s concerns here. If RS wants to take info in nav and process it into native UI elements, we are not preventing them from doing anything. They can look for XML lang if they want.
… and then what they do with that is up to them
… to gpellegrino’s point about advising authors, I don’t think that’s a good idea because we also have the idea of displaying the nav in the spine, and ensuring that it gets presented as HTML, and where all these attributes will be honored

Hadrien Gardeur: i think it comes back to the fact that we’re trying to serve two goals: 1) machine readable view, and 2) document view/webview
… but trying to do both in same document we’re always going to have conflicts between those goals
… i don’t think we can solve both needs with single document
… the only way to fix it is to basically have one thing that is meant to be processed, and another thing meant to be rendered the way it would be on the web
… this is how I’d deal with this eventually

Murata Makoto: Yes, I was writing an email about the use of ruby in nav docs to my colleagues in JDC.

Matt Garrish: i wonder if what is missing here is that there are requirements on how to create the text label. It’s in the RS spec.
… maybe we could link to those?

Dave Cramer: yeah, that kind of makes sense

Brady Duga: in terms of lang, we’re probably right by chance because people usually read books in the same language that their RS is set to. But we’ve never received a complaint about this.
… but it is a good point that was made by gpellegrino

Dave Cramer: we’re not in a position to change the processing rules, even if using the same doc for processing and rendering removes duplication
… i would close this, but incorporate mgarrish suggestion to link back to RS spec

Gregorio Pellegrino: may I add the issue to epub next so we don’t lose track of it?

Dave Cramer: yes

Matt Garrish: maybe the point about lang is a statement we can make in the a11y section. Just to say that any UI should be accessible.

Dave Cramer: yes

Proposed resolution: Add clarifying link to authoring specification, label issue as EPUB next and close issue 1775 (Wendy Reid)

Gregorio Pellegrino: +1

Wendy Reid: +1

Deborah Kaplan: “1

Matt Garrish: +1

Deborah Kaplan: +1

Toshiaki Koike: +1

Brady Duga: +1

Dave Cramer: +1

Tzviya Siegman: +1

Matthew Chan: +1

Bill Kasdorf: +1

Masakazu Kitahara: +1

Dan Lazin: +1

Murata Makoto: +1

Avneesh Singh: +1

Ben Schroeter: +1

Resolution #3: Add clarifying link to authoring specification, label issue as EPUB next and close issue 1775

George Kerscher: +1

4. Enabling zoom in FXL EPUBs

See github issue #1776.

Dave Cramer: should we point out that zooming is important for a11y, even in the context of FXL epub?

Gregorio Pellegrino: my idea is to add SHOULD statement. “FXL SHOULD enable zooming”

Hadrien Gardeur: what makes it difficult is the fact that you can have spreads in FXL
… could be two iframes or two webviews. This makes it difficult to zoom in a good way because you have those two things side by side
… but not saying that we shouldn’t do it

Dave Cramer: right, so what would happen if you try to zoom in on the boundary between two documents?

Matt Garrish: aren’t we getting into UI requirements again? Not sure if this is always feasible.
… maybe this is something we could just point out. Or move this over to the FXL a11y doc rather that in the core spec.

Dave Cramer: do we know of existing RS that allow for zoom in FXL

Gregorio Pellegrino: yes, all the mobile RS

Matt Garrish: but that’s a feature of the mobile RS

Brady Duga: that’s quite a bit of implementation on the mobile side, its not free
… but on the desktop side its a bit easier
… and yes, spreads add complication

Wendy Reid: almost the same comment as duga. Sometimes you see it implemented as a slider rather than pinch to zoom
… uncomfortable with adding this to spec because we don’t talk about UI or UX affordances
… not sure we want to get into that territory
… but we can add this as a recommendation in the FXL a11y doc

Avneesh Singh: i think this isn’t something for the FXL content side of things. Maybe we can add statement on RS side encouraging the provision of zoom for FXL content. But not make this a normative statement.

Dave Cramer: getting the sense that a lot of RS already allow this. And historically we don’t describe UX features in spec. I would note this in FXL a11y document rather than epub spec itself.

Gregorio Pellegrino: my small concern is that the FXL note is more for authors than RS, so the suggestion may get ignored

Dave Cramer: are there implementations of FXL epub that don’t allow zooming?

Gregorio Pellegrino: yes, on desktop some don’t allow this

Dave Cramer: are we okay with adding something non-normative to RS spec?

Deborah Kaplan: mgarrish++

Matt Garrish: can we add this to the a11y section? Just a suggestion to provide the option to allow user to zoom in

Avneesh Singh: +1 to genrral statement in a11y section of RS

Gregorio Pellegrino: maybe link to FXL best practices document?

Deborah Kaplan: +1 as well, ditto mgarrish and avneesh

Matt Garrish: yes, once we get to FPWD we can link to it

Proposed resolution: Add a note to the accessibility section of the reading systems document, add mention in FXL accessibility note, close issue 1776 (Wendy Reid)

Gregorio Pellegrino: +1

Dave Cramer: +1

Matthew Chan: +1

Wendy Reid: +1

Matt Garrish: +1

Deborah Kaplan: +1

Tzviya Siegman: +1

Toshiaki Koike: +1

Masakazu Kitahara: +1

Ben Schroeter: +1

Dan Lazin: +1

Bill Kasdorf: +1

Brady Duga: +1

Resolution #4: Add a note to the accessibility section of the reading systems document, add mention in FXL accessibility note, close issue 1776

Dave Cramer: RRSAgent: bye

5. Resolutions