13:50:12 <RRSAgent> RRSAgent has joined #epub
13:50:12 <RRSAgent> logging to https://www.w3.org/2021/08/27-epub-irc
13:50:14 <Zakim> RRSAgent, make logs Public
13:50:15 <Zakim> please title this meeting ("meeting: ..."), dauwhe
13:50:26 <dauwhe> meeting: EPUB 3 Working Group Telecon
13:50:28 <dauwhe> chair: dauwhe
13:50:39 <dauwhe> Date: 2021-08-27
13:51:15 <dauwhe> dauwhe has changed the topic to: https://lists.w3.org/Archives/Public/public-epub-wg/2021Aug/0030.html
13:58:18 <wendyreid> wendyreid has joined #epub
13:58:39 <mgarrish> mgarrish has joined #epub
13:58:43 <dauwhe> present+
13:58:51 <BenSchroeter> BenSchroeter has joined #epub
13:58:58 <tzviya> tzviya has joined #epub
13:59:14 <gpellegrino> gpellegrino has joined #epub
13:59:20 <MasakazuKitahara> MasakazuKitahara has joined #epub
13:59:22 <toshiakikoike> toshiakikoike has joined #epub
13:59:27 <MasakazuKitahara> present+
13:59:32 <gpellegrino> present+
13:59:34 <toshiakikoike> present+
13:59:34 <avneeshsingh> avneeshsingh has joined #epub
13:59:38 <MattChan> MattChan has joined #epub
13:59:39 <avneeshsingh> present+
13:59:53 <dkaplan3> dkaplan3 has joined #epub
13:59:54 <Karen> Karen has joined #epub
13:59:55 <wendyreid> present+
13:59:57 <MattChan> present+
13:59:59 <dkaplan3> present+
14:00:04 <BenSchroeter> present+
14:00:37 <duga> duga has joined #epub
14:00:48 <duga> present+
14:00:50 <dlazin> dlazin has joined #epub
14:00:55 <dlazin> present+
14:01:00 <MattChan> scribe+
14:01:21 <tzviya> present+
14:01:28 <mgarrish> present+
14:02:23 <MattChan> dauwhe: are there any new people?
14:02:31 <MattChan> Aimee: yes, hello!
14:02:39 <MattChan> Jen: Also new. I work with Aimee.
14:02:59 <MattChan> Aimee: we're focused on document a11y. A11y PDF specifically.
14:03:01 <Bill_Kasdorf> Bill_Kasdorf has joined #epub
14:03:06 <MattChan> ... here to contribute and learn!
14:03:37 <MattChan> Jen: I'm a braille reader. Read a lot of epub in my real life, in addition to having a professional interest!
14:03:48 <MattChan> George: Welcome!
14:04:03 <dauwhe> https://github.com/w3c/epub-specs/issues/1761
14:04:06 <MattChan> TOPIC: Landmarks Nav
14:04:21 <MattChan> dauwhe: what is the purpose of landmark nav?
14:04:23 <AUbbink> AUbbink has joined #epub
14:05:14 <MattChan> mgarrish: this is a continuing question. We created it originally to aid RS with hotkeys that go to specific parts of epub, stuff like that.
14:05:31 <dlazin> q+
14:05:37 <MattChan> ... but do RS even use these? And what are authors supposed to put in here?
14:05:50 <MattChan> ... RS couldn't rely on there being specific content in here
14:05:54 <AUbbink> present+ Aimee
14:06:08 <MattChan> ... closest thing to standard is link to start of bodymatter
14:06:34 <MattChan> ... 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?
14:06:42 <duga> q+
14:06:44 <dauwhe> ack dlazin
14:06:46 <George> George has joined #epub
14:07:05 <George> present+
14:07:22 <George> q+
14:07:36 <MattChan> dlazin: does that disagree with the explanation at the last meeting, which said that we've had landmark since epub1?
14:07:46 <MattChan> s/epub1/epub2
14:08:24 <MattChan> mgarrish: i think dauwhe was getting at guides, which were kind of like a tour of the content. A little different.
14:08:41 <Hadrien> Hadrien has joined #epub
14:08:49 <MattChan> dlazin: if this feature hasn't been adopted widely by this point, it sounds like the sort of thing that ought to be deprecated
14:08:52 <dauwhe> ack duga
14:09:01 <Hadrien> present+
14:09:07 <tzviya> q+ to comment on guide v landmark
14:09:25 <MattChan> 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.
14:09:31 <MattChan> ... and its used for that purpose widely
14:09:37 <George> George has joined #epub
14:09:38 <MattChan> ... would be odd to deprecate it in that case
14:09:41 <dauwhe> ack George
14:10:05 <MattChan> George: screenreaders have had keys that go to landmarks, which has been useful
14:10:26 <MattChan> ... i've heard from students when there are landmarks in each chapter that provide an overview of said chapter
14:10:47 <MattChan> ... 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
14:10:49 <MURATA> MURATA has joined #epub
14:11:14 <MattChan> dauwhe: are these things implemented in RS based on landmark?
14:11:21 <mgarrish> q+
14:11:32 <MattChan> george: as long as theres a landmark in the DOM than the screenreader can go to it
14:11:38 <George> George has joined #epub
14:11:48 <MattChan> dauwhe: we might be using "landmark" to refer to two different things?
14:11:54 <dauwhe> ack tz
14:11:54 <Zakim> tzviya, you wanted to comment on guide v landmark
14:11:59 <MattChan> george: Referring to ARIA landmark here
14:12:06 <Hadrien> q+
14:12:21 <MattChan> tzviya: right, ARIA landmarks are a different thing. And this has lead to confusion over the years
14:13:13 <MattChan> ... 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.
14:13:29 <MattChan> ... but some books are starting to use it to duplicate toc, which makes it less useful
14:13:38 <George> George has joined #epub
14:13:55 <dauwhe> ack mg
14:13:56 <MattChan> ... i would hesitate to deprecate entirely, but maybe offer guidance to make landmark more useful
14:14:43 <avneeshsingh> +1 for not deprecating landmark. we should provide some guidance.
14:14:45 <MattChan> mgarrish: 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
14:15:07 <dlazin> q+
14:15:14 <MattChan> ... this could head people off before they get confused
14:15:18 <dauwhe> ack Ha
14:15:38 <George> George has joined #epub
14:16:12 <MattChan> Hadrien: 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.
14:16:31 <gpellegrino> q+
14:16:39 <dauwhe> ack dl
14:16:45 <MattChan> dauwhe: Identifying the point where people would start reading is valuable for the reader, but what is the best way to accomplish that?
14:17:04 <MattChan> dlazin: my interpretation is that deprecating something already used doesn't mean that the thing is going away immediately
14:17:23 <MattChan> ... it means we're leaving this, and there is spotty implementation
14:17:27 <mgarrish> q+
14:17:38 <George> George has joined #epub
14:17:56 <dauwhe> https://w3c.github.io/epub-specs/epub33/core/#deprecated
14:18:12 <MattChan> ... if you are new RS or author, it tells you this is not high on your list of features
14:18:17 <dauwhe> ack gp
14:18:20 <avneeshsingh> q+
14:18:22 <duga> q+
14:18:46 <MattChan> gpellegrino: another use case that I know of is being able to jump to the in-book toc
14:18:57 <MattChan> ... i.e. not the nav toc
14:18:59 <dauwhe> ack mg
14:19:38 <George> George has joined #epub
14:19:57 <MattChan> mgarrish: 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.
14:20:45 <MattChan> ... 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.
14:20:46 <dauwhe> ack avn
14:21:02 <MattChan> avneeshsingh: coming back to main principles in charter, we have backwards compat clause
14:21:37 <George> George has joined #epub
14:21:39 <MURATA> +1
14:22:00 <dauwhe> ack duga
14:22:07 <MattChan> ... 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
14:22:38 <MattChan> 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.
14:22:43 <dauwhe> q?
14:22:49 <MattChan> ... and it is the recommended way, in fact.
14:22:56 <dauwhe> q+
14:23:10 <dauwhe> ack dau
14:23:17 <MattChan> ... and maybe we can return to this and set out a different way to do it in the future.
14:23:25 <MattChan> ... but for now, I'm very much against deprecation
14:23:38 <George> George has joined #epub
14:23:50 <MattChan> dauwhe: 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.
14:24:07 <MattChan> ... not a new toc, or a completely different way of traversing the content
14:24:14 <George> George has joined #epub
14:24:15 <MattChan> ... maybe all that is needed for now is some editorial work
14:24:20 <MattChan> ... does that seem reasonable?
14:24:23 <MattChan> duga: yes
14:24:25 <MURATA> Good  to me.
14:25:13 <wendyreid> Proposed: Clarify the language for landmarks, close issue 1761
14:25:16 <dkaplan3> +1
14:25:16 <tzviya> +1
14:25:16 <dauwhe> +1
14:25:19 <toshiakikoike> +1
14:25:19 <duga> +1
14:25:20 <mgarrish> +1
14:25:20 <dlazin> +1
14:25:20 <avneeshsingh> +1
14:25:21 <gpellegrino> +1
14:25:21 <MasakazuKitahara> +1
14:25:23 <MattChan> +1
14:25:23 <MURATA> +1
14:25:24 <wendyreid> +1
14:25:25 <Bill_Kasdorf> +1
14:25:26 <BenSchroeter> +1
14:25:36 <wendyreid> RESOLVED: Clarify the language for landmarks, close issue 1761
14:25:38 <George> George has joined #epub
14:26:02 <dauwhe> https://github.com/w3c/epub-specs/issues/1774
14:26:04 <MattChan> TOPIC: XHTML and SVG
14:26:43 <MattChan> dauwhe: apparently the SVG content doc section says RS should support searching of text, but the XHTML content doc section doesn't mention searching
14:27:30 <mgarrish> q+
14:27:31 <MattChan> ... i see the point, but I'm also concerned that in general we try to avoid describing how RS should present epub to users
14:27:34 <dauwhe> ack mg
14:27:38 <George> George has joined #epub
14:27:44 <MattChan> ... my preference is to take out the line about SVG
14:28:22 <duga> q+
14:28:45 <MattChan> mgarrish: 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.
14:28:51 <tzviya> +1 to mgarrish
14:28:59 <dauwhe> ack dug
14:28:59 <MattChan> ... maybe just a note reminding RS people that SVGs can contain text
14:29:38 <George> George has joined #epub
14:29:49 <MattChan> 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.
14:30:01 <MattChan> wendyreid: gpellegrino which would you prefer, since it is your issue?
14:30:17 <George> George has joined #epub
14:30:32 <MattChan> gpellegrino: no position as it doesn't strongly impact a11y. I just wanted to point out this discrepancy.
14:31:23 <MattChan> dauwhe: 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.
14:32:02 <wendyreid> Proposed: Remove the search point from the SVG section, close issue 1774
14:32:04 <BenSchroeter> +1
14:32:04 <duga> +1
14:32:05 <tzviya> +1
14:32:06 <dkaplan3> +0
14:32:08 <gpellegrino> +1
14:32:08 <toshiakikoike> +1
14:32:08 <MattChan> +1
14:32:10 <wendyreid> +1
14:32:10 <dlazin> +1
14:32:11 <mgarrish> +!
14:32:11 <dauwhe> +1
14:32:12 <MasakazuKitahara> +1
14:32:15 <MURATA> +1
14:32:16 <Bill_Kasdorf> +1
14:32:42 <wendyreid> RESOLVED: Remove the search point from the SVG section, close issue 1774
14:32:50 <dauwhe> https://github.com/w3c/epub-specs/issues/1775
14:32:54 <MattChan> TOPIC: Navigation Document Processing
14:33:04 <George> George has joined #epub
14:33:14 <Jen_G> Jen_G has joined #epub
14:33:33 <MattChan> dauwhe: this is related to things we've discussed in the past. Our nav is HTML, so it can include ARIA attributes, lang, etc.
14:33:38 <George> George has joined #epub
14:33:43 <Hadrien> q+
14:33:48 <mgarrish> q+
14:33:57 <gpellegrino> q+
14:33:58 <MattChan> ... gpellegrino proposes that we remind RS that they should honor these sorts of attributes when they present nav content in UI
14:34:10 <George> George has joined #epub
14:34:21 <MattChan> ... but some RS just strip everything except the text value of the stuff in nav
14:34:22 <dauwhe> ack Ha
14:34:50 <George> George has joined #epub
14:35:00 <MattChan> Hadrien: I'm worried about this. There are very good reason why RS do that.
14:35:14 <MattChan> ... if we change this RS cannot use native UI elements to present nav
14:35:22 <MattChan> ... would have to be a webview
14:35:44 <MattChan> ... I don't think what is being suggested is achievable
14:35:46 <dauwhe> ack mg
14:37:04 <dauwhe> q+
14:37:12 <dauwhe> ack gp
14:37:15 <MattChan> mgarrish: 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.
14:37:38 <George> George has joined #epub
14:38:22 <MattChan> gpellegrino: 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.
14:38:26 <dauwhe> ack
14:39:17 <MattChan> dauwhe: 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.
14:39:27 <MattChan> ... and then what they do with that is up to them
14:39:38 <George> George has joined #epub
14:40:07 <Hadrien> q+
14:40:10 <dauwhe> ack dau
14:40:13 <dauwhe> ack ha
14:40:20 <MattChan> ... 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
14:40:37 <George> George has joined #epub
14:40:47 <MattChan> Hadrien: 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
14:40:55 <dauwhe> q?
14:41:02 <MattChan> ... but trying to do both in same document we're always going to have conflicts between those goals
14:41:12 <George> George has joined #epub
14:41:25 <MattChan> ... i don't think we can solve both needs with single document
14:41:47 <tzviya> q+
14:42:04 <MattChan> ... 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
14:42:12 <mgarrish> q+
14:42:18 <dauwhe> ack tz
14:42:20 <MattChan> ... this is how I'd deal with this eventually
14:42:38 <MURATA> Yes, I was writing an email about the use of ruby in nav docs to my colleagues in JDC.
14:42:45 <dauwhe> q+
14:42:58 <dauwhe> ack mg
14:43:29 <MattChan> mgarrish: 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.
14:43:38 <George> George has joined #epub
14:43:39 <MattChan> ... maybe we could link to those?
14:43:54 <dauwhe> ack dau
14:44:02 <MattChan> dauwhe: yeah, that kind of makes sense
14:44:05 <duga> q+
14:44:12 <dauwhe> ack du
14:45:12 <MattChan> 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.
14:45:25 <MattChan> ... but it is a good point that was made by gpellegrino
14:45:38 <George> George has joined #epub
14:46:02 <gpellegrino> q+
14:46:04 <MattChan> dauwhe: we're not in a position to change the processing rules, even if using the same doc for processing and rendering removes duplication
14:46:10 <dauwhe> ack gp
14:46:15 <MattChan> ... i would close this, but incorporate mgarrish suggestion to link back to RS spec
14:46:29 <mgarrish> q+
14:46:34 <MattChan> gpellegrino: may I add the issue to epub next so we don't lose track of it?
14:46:37 <dauwhe> ack mg
14:46:38 <MattChan> dauwhe: yes
14:47:08 <MattChan> mgarrish: maybe the point about lang is a statement we can make in the a11y section. Just to say that any UI should be accessible.
14:47:10 <dauwhe> q?
14:47:20 <MattChan> dauwhe: yes
14:47:30 <wendyreid> Proposed: Add clarifying link to authoring specification, label issue as EPUB next and close issue 1775
14:47:32 <gpellegrino> +1
14:47:34 <wendyreid> +1
14:47:35 <dkaplan3> "1
14:47:35 <mgarrish> +1
14:47:37 <dkaplan3> +1
14:47:37 <toshiakikoike> +1
14:47:37 <duga> +1
14:47:37 <dauwhe> +1
14:47:38 <George> George has joined #epub
14:47:39 <tzviya> +1
14:47:39 <MattChan> +1
14:47:39 <Bill_Kasdorf> +1
14:47:40 <MasakazuKitahara> +1
14:47:40 <dlazin> +1
14:47:43 <MURATA> +1
14:47:43 <avneeshsingh> +1
14:47:44 <BenSchroeter> +1
14:47:47 <wendyreid> RESOLVED: Add clarifying link to authoring specification, label issue as EPUB next and close issue 1775
14:47:54 <George> +1
14:48:04 <dauwhe> https://github.com/w3c/epub-specs/issues/1776
14:48:07 <MattChan> TOPIC: Enabling zoom in FXL EPUBs
14:48:37 <dauwhe> q?
14:48:39 <MattChan> dauwhe: should we point out that zooming is important for a11y, even in the context of FXL epub?
14:48:53 <gpellegrino> q+
14:48:56 <dauwhe> ack gp
14:49:10 <Hadrien> q+
14:49:16 <dauwhe> ack Ha
14:49:17 <MattChan> gpellegrino: my idea is to add SHOULD statement. "FXL SHOULD enable zooming"
14:49:38 <George> George has joined #epub
14:49:39 <MattChan> Hadrien: what makes it difficult is the fact that you can have spreads in FXL
14:50:05 <MattChan> ... 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
14:50:20 <mgarrish> q+
14:50:25 <MattChan> ... but not saying that we shouldn't do it
14:50:33 <dauwhe> ack mg
14:50:38 <George> George has joined #epub
14:50:40 <MattChan> dauwhe: right, so what would happen if you try to zoom in on the boundary between two documents?
14:50:50 <dauwhe> q+
14:50:57 <MattChan> mgarrish: aren't we getting into UI requirements again? Not sure if this is always feasible.
14:51:20 <MattChan> ... maybe this is something we could just point out. Or move this over to the FXL a11y doc rather that in the core spec.
14:51:28 <dauwhe> ack dau
14:51:29 <wendyreid> q+
14:51:33 <MattChan> dauwhe: do we know of existing RS that allow for zoom in FXL
14:51:41 <MattChan> gpellegrino: yes, all the mobile RS
14:51:41 <avneeshsingh> q+
14:51:50 <MattChan> mgarrish: but that's a feature of the mobile RS
14:52:04 <MattChan> duga: that's quite a bit of implementation on the mobile side, its not free
14:52:17 <MattChan> ... but on the desktop side its a bit easier
14:52:40 <dauwhe> ack wen
14:52:45 <MattChan> ... and yes, spreads add complication
14:53:08 <MattChan> wendyreid: almost the same comment as duga. Sometimes you see it implemented as a slider rather than pinch to zoom
14:53:25 <MattChan> ... uncomfortable with adding this to spec because we don't talk about UI or UX affordances
14:53:31 <MattChan> ... not sure we want to get into that territory
14:53:37 <George> George has joined #epub
14:53:50 <dauwhe> ack avn
14:53:51 <MattChan> ... but we can add this as a recommendation in the FXL a11y doc
14:54:14 <George> George has joined #epub
14:54:46 <MattChan> avneeshsingh: 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 in FXL content. But not make this a normative statement.
14:54:46 <dauwhe> q?
14:55:06 <MattChan> s/zoom in FXL content/zoom for FXL content
14:55:33 <MattChan> dauwhe: 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.
14:55:36 <gpellegrino> q+
14:55:38 <George> George has joined #epub
14:55:40 <dauwhe> ack gp
14:56:07 <MattChan> gpellegrino: my small concern is that the FXL note is more for authors than RS, so the suggestion may get ignored
14:56:19 <MattChan> dauwhe: are there implementations of FXL epub that don't allow zooming?
14:56:26 <MattChan> gpellegrino: yes, on desktop some don't allow this
14:57:10 <mgarrish> q+
14:57:11 <gpellegrino> q+
14:57:13 <MattChan> dauwhe: are we okay with adding something non-normative to RS spec?
14:57:14 <dauwhe> ack mg
14:57:45 <dkaplan3> mgarrish++
14:57:45 <dauwhe> ack gp
14:57:51 <MattChan> mgarrish: can we add this to the a11y section? Just a suggestion to provide the option to allow user to zoom in
14:57:57 <avneeshsingh> +1 to genrral statement in a11y section of RS
14:58:10 <MattChan> gpellegrino: maybe link to FXL best practices document?
14:58:18 <dkaplan3> +1 as well, ditto mgarrish and avneesh
14:58:31 <MattChan> mgarrish: yes, once we get to FPWD we can link to it
14:59:21 <wendyreid> Proposed: Add a note to the accessibility section of the reading systems document, add mention in FXL accessibility note, close issue 1776
14:59:23 <gpellegrino> +1
14:59:24 <dauwhe> +1
14:59:25 <MattChan> +1
14:59:25 <wendyreid> +1
14:59:25 <mgarrish> +1
14:59:26 <dkaplan3> +1
14:59:27 <tzviya> +1
14:59:28 <toshiakikoike> +1
14:59:28 <MasakazuKitahara> +1
14:59:29 <BenSchroeter> +1
14:59:30 <dlazin> +1
14:59:30 <Bill_Kasdorf> +1
14:59:36 <duga> +1
14:59:39 <wendyreid> Resolved: Add a note to the accessibility section of the reading systems document, add mention in FXL accessibility note, close issue 1776
15:00:55 <dauwhe> Zakim, end meeting
15:00:55 <Zakim> As of this point the attendees have been dauwhe, MasakazuKitahara, gpellegrino, toshiakikoike, avneeshsingh, wendyreid, MattChan, dkaplan, BenSchroeter, duga, dlazin, tzviya,
15:00:58 <Zakim> ... mgarrish, Aimee, George, Hadrien, !
15:00:58 <Zakim> RRSAgent, please draft minutes
15:00:58 <RRSAgent> I have made the request to generate https://www.w3.org/2021/08/27-epub-minutes.html Zakim
15:01:00 <Zakim> I am happy to have been of service, dauwhe; please remember to excuse RRSAgent.  Goodbye
15:01:03 <dkaplan3> dkaplan3 has left #epub
15:01:05 <Zakim> Zakim has left #epub
15:01:26 <dauwhe> RRSAgent: bye
15:01:26 <RRSAgent> I see no action items