13:37:06 RRSAgent has joined #epub 13:37:06 logging to https://www.w3.org/2021/10/28-epub-irc 13:37:08 RRSAgent, make logs Public 13:37:10 please title this meeting ("meeting: ..."), ivan 13:37:34 Meeting: APA + EPUB 3 Joint Meeting 13:38:15 Agenda: https://www.w3.org/events/meetings/35bce778-3fec-40d6-a6e1-30ff6961616a/edit#agenda 13:50:23 Karen has joined #epub 13:54:13 rickj has joined #epub 13:54:34 wendyreid has joined #epub 13:54:59 present+ 13:55:35 janina has joined #epub 13:55:59 present+ 13:56:05 present+ 13:56:22 avneeshsingh has joined #epub 13:57:02 present+ 13:57:36 shiestyle has joined #epub 13:58:50 present+ 13:58:53 mgarrish has joined #epub 13:59:02 PaulG has joined #epub 13:59:18 shadi has joined #epub 13:59:24 BenSchroeter has joined #epub 13:59:32 present+ 13:59:42 duga has joined #epub 14:00:22 SamKanta has joined #epub 14:00:27 present+ 14:00:34 present+ 14:01:00 CharlesL has joined #epub 14:01:09 MattChan has joined #epub 14:01:10 present+ 14:01:14 present+ 14:01:30 JF has joined #epub 14:01:37 present+ 14:01:39 Present+ 14:01:50 present+ 14:02:20 Roy has joined #epub 14:02:36 present+ 14:02:47 agenda? 14:03:09 have to jump to another call halfway through 14:03:12 George has joined #epub 14:03:16 present+ 14:03:41 chair: janina 14:04:05 present+ 14:04:12 Victor_Lopes has joined #epub 14:04:24 Bill_Kasdorf has joined #epub 14:05:08 John_Roque has joined #epub 14:06:06 scribe+ 14:06:06 becky has joined #epub 14:06:10 George has joined #epub 14:07:13 kirkwood has joined #epub 14:08:10 George has joined #epub 14:09:46 present+ jasonjgw 14:09:56 present+ victoria 14:10:00 present+ roy 14:10:10 George has joined #epub 14:10:26 victoria has joined #epub 14:10:36 janina: the topic is the request for horizontal review 14:10:46 ... we put 2 people on each spec to read 14:11:01 ... we didn't find much beyond nits, some of which have already been filed on github 14:11:23 ... (not surprising because there is a lot of a11y expertise in epub wg) 14:11:28 present+ John Roque 14:11:59 zakim, who is here? 14:11:59 Present: rickj, wendyreid, janina, dauwhe_, tzviya, shadi, BenSchroeter, SamKanta, CharlesL, MattChan, shiestyle, JF, duga, ivan, George, PaulG, jasonjgw, victoria, roy, John, 14:12:03 ... Roque 14:12:03 On IRC I see victoria, kirkwood, becky, John_Roque, Bill_Kasdorf, Victor_Lopes, Roy, JF, MattChan, CharlesL, SamKanta, duga, BenSchroeter, shadi, PaulG, mgarrish, shiestyle, 14:12:03 ... avneeshsingh, janina, wendyreid, rickj, Karen, RRSAgent, Zakim, bkardell_, tzviya, ShawnT, ivan, join_subline, dauwhe_, hober, mateus, florian, weiler, jcraig, Joshue108, 14:12:03 ... github-bot, AramZS 14:12:10 George has joined #epub 14:12:12 ... let's give each of the spec reviewers a chance to speak now 14:12:15 present+ 14:12:15 present+ 14:12:20 ShawnT has left #epub 14:12:22 present+ 14:12:40 ... i have some thoughts about the future of epub, and we can spend some time on that 14:12:50 ... we have some emerging specs that will be of interest to epub 14:13:00 ... e.g. support for people with cognitive and learning disabilities 14:13:10 q? 14:13:10 George has joined #epub 14:13:18 ... (thanks to CharlesL for help on that, and to our several participants from the pronunciation TF) 14:13:29 present+ becky 14:14:08 ... and will there be an epub 3.4? Or maybe some more major jumps in the future? 14:14:10 q+ 14:14:16 ack avneeshsingh 14:14:18 ... any more topics to be tabled? 14:14:31 avneeshsingh: we had some questions about respec 14:14:46 janina: i refer questions about respec to michael, maybe jason could speak to it 14:14:47 agenda+ Reviewing the Specifications 14:14:51 q+ 14:14:57 agenda+ The Future of EPUB 14:15:02 agenda+ AOB 14:15:08 jason: i've read the documentation and used it to an extent, not necessarily an expert 14:15:24 ack mgarrish 14:15:26 present+ FredrikFischer, AndrewNevins 14:15:31 janina: we can talk about respec, but maybe we should try to get michael into a call 14:15:47 mgarrish: we don't have to solve respec issues today, but i'm curious what the process would be 14:15:52 q+ 14:16:10 George has joined #epub 14:16:24 ... who is responsible for changes to respec output? We don't want to affect all w3c specs 14:16:37 q+ 14:16:51 janina: sure, let's just discuss issues for today without needing to solve anything, necessarily 14:16:54 ack tzviya 14:17:37 anevins__ has joined #epub 14:17:37 tzviya: there's a group called spec prod, an email list. Try there. Michael would funnel questions to this group. 14:18:05 ... one issue recently is about CR vs TR, and whether notes have a formal standing in W3C world 14:18:10 George has joined #epub 14:18:30 janina: and i think there are new vehicles: e.g. registries, W3C statements 14:18:48 ack ivan 14:18:51 ... notes could conceivably have more impact than they've had in the past 14:19:10 ivan: the new process will become official on the 2nd Nov 14:19:39 TOPIC: epub a11y 1.1 review 14:19:40 zakim, next item 14:19:41 agendum 1 -- Reviewing the Specifications -- taken up [from wendyreid] 14:20:10 George has joined #epub 14:20:18 jason: i filed some issues in githubt, but they are being handled 14:20:27 q+ 14:20:31 q+ 14:20:35 q+ 14:20:47 ack mgarrish 14:20:53 ... question about how this spec will adapt to future versions of WCAG a11y guidelines 14:21:34 janina: i've been working with SILVER, and i love the statement about a11y conformance applying to the whole book (not just a page or two) 14:21:50 mgarrish: difficulty is trying to anticipate what future of WCAG will be 14:22:01 ... we know it'll be moving to a gold/silver etc. system 14:22:10 George has joined #epub 14:22:16 ... in the meantime we refer to the current WCAG standard 14:22:43 janina: speaking as APA chair, the biggest difference is that we're going to try to build in a little wiggle room 14:23:07 Q+ 14:23:41 ... so that the standard of conformance is not perfection, to allow for particular situations, to try to understand what role a spec plays vs policy decisions/legislation that happen at a government level 14:23:49 ... exactly how that will play out is still being debated 14:23:54 ack anevins__ 14:24:03 andrew: my issues in github are being tackled, thank you 14:24:06 q- 14:24:10 George has joined #epub 14:24:47 ... one thing is that a script is being used to generate perma-links, i think mgarrish mentioned that this relates to a larger problem 14:24:58 present+ anevins__ 14:25:55 mgarrish: right, I hacked up a script that post-processes our document to solve the issue you alluded to, works for epub but its really something that should be fixed in respec 14:26:07 ... not sure that i'm the one that should be making those changes 14:26:10 George has joined #epub 14:26:27 ... so we have a temporary patch, but how much temporary patching do we want to do? 14:26:45 janina: it doesn't sound like a WCAG issue to me 14:27:39 q+ 14:27:45 ... how often do you republish? 14:27:51 ack JF 14:27:54 mgarrish: every time there's a PR being merged 14:28:05 https://docs.google.com/spreadsheets/d/1yzR1H0SnNFRELGchb_BJr4Necsrj6xVjDF1n7Tc0kTc/edit#gid=0 14:28:10 George has joined #epub 14:28:26 Fredrik has joined #epub 14:28:31 present+ 14:28:38 q- 14:28:39 JF: this is a google docs worksheet that is a working timeline for project SILVER 14:28:50 ... it suggests that they're still 5 years out from completion 14:28:50 George has joined #epub 14:29:13 ... so i appreciate that we thinking ahead, but for epub we can probably stick to thinking about a shorter timeframe 14:29:23 TOPIC: epub33 RS review 14:29:53 becky: didn't find issues, but i wasn't looking for respec type issues 14:30:03 TOPIC: epub 33 core review 14:30:28 q+ 14:30:38 ack wendyreid 14:30:42 janina: i reviewed along with some others. No real issues, but I was surprised by some of the fixed format stuff 14:30:58 q+ 14:31:30 wendyreid: FXL is a part of the industry that epub 3 made official. This content is primarily used for comics, print-replica content (e.g. cookbooks). We know about the a11y issues here. 14:31:52 ... the WG is working on a note that gives guidance specifically on FXL a11y 14:32:10 George has joined #epub 14:32:52 ... the note is meant to add onto the core spec by suggesting the recommended way of doing things in FXL 14:32:53 q- 14:33:11 https://w3c.github.io/epub-specs/epub33/fxl-a11y/ 14:33:21 dauwhe_: with FXL its largely a way of taking advantage of things that already exist in HTML and CSS 14:33:38 ... and this stuff can be used well, or be misused from a11y point of view 14:33:44 ... that's why we need guidelines 14:33:48 q? 14:34:10 George has joined #epub 14:34:13 q+ 14:34:13 ... there's also the added complication in epub of creating a spread (two different HTML pages side by side) that has no web analogue 14:34:14 q+ 14:34:18 ack avneeshsingh 14:34:34 George has joined #epub 14:34:47 avneeshsingh: can we officially say that epub 33 has passed APA horizontal review? 14:35:17 ack mgarrish 14:35:26 janina: i don't hear any objections. There's a checkbox that we need to check on our end, and that'll be coming up soon 14:35:33 George has joined #epub 14:36:22 mgarrish: and when there are books that are bilingual, sometimes there are books where content in both languages are displayed side-by-side 14:36:31 ... that's a problem that isn't unique to FXL 14:37:07 janina: yes, interlinear text can be helpful for language learning. I've seen examples of this in practice. 14:37:21 q+ 14:37:30 q+ 14:38:09 ... maybe we can setup a working session together in the future 14:38:10 George has joined #epub 14:38:11 ack tzviya 14:38:11 The Harvard Univ. Press's Loeb Classical Library is a really great example of English + Greek and English + Latin side-by-side. 14:38:54 tzviya: janina mentioned a number of tools that do this sort of thing (e.g. Duolingo, bablefish) 14:39:08 ... bible software is way more advanced in this field than general publishing 14:39:17 ... dictionary software doesn't apply as directly 14:39:36 ... i know a handful of people who might have experience doing this sort of thing 14:39:43 https://chaucer.fas.harvard.edu/pages/literary-works 14:39:46 ack CharlesL 14:39:55 Harvard would have the resources and mission to help address this. 14:40:10 George has joined #epub 14:40:13 janina: this is a link to a Harvard page that is an interlinear version of Canterbury Tales 14:40:44 CharlesL: this came up in a11y certification in Canada, e.g. a book that has both the english and french translation of a book 14:41:04 ... because publishers want to do this, we're probably going to see this more and more 14:41:27 janina: i hope we can do this in a way that isn't fixed layout 14:41:31 In the Loeb the English is on the verso and the Greek and Latin is on the recto--facing pages aligning across. 14:42:10 George has joined #epub 14:42:14 george: when we come up with a recommendation to the publisher on what we think works, maybe we could have some people review it and comment. Maybe the results could go into DAISY kb. 14:42:38 http://www.perseus.tufts.edu/hopper/opensource 14:42:39 janina: people have mentioned side-by-side, like in an opera libretto 14:43:23 q+ 14:43:23 ... the other way to do it is a line on top of a line 14:43:46 ack ivan 14:43:47 ... this offers more of a word-for-word comparison 14:44:01 ivan: isn't what you're describing Ruby? 14:44:10 George has joined #epub 14:44:13 ... it was designed for eastern languages, but we might be able to use it for this as well 14:44:22 q+ 14:44:27 ... but i'm not sure if implementations of Ruby are accessible or not 14:44:30 ack duga 14:44:40 https://www.normanet.ne.jp/~jdc/tech/index.html 14:44:52 duga: there was an open letter to W3C from DAISY japan about Ruby, so I'm guessing it isn't very accessible 14:45:28 wendyreid: letter was just sent to us today, it's about the inaccessibility of Ruby (link above) 14:45:53 q+ to ask who letter was sent to 14:45:56 q+ 14:45:58 ... this is something we probably all want to work on, and especially if we are expanding use cases for it 14:46:00 ack tzviya 14:46:00 tzviya, you wanted to ask who letter was sent to 14:46:05 dkaplan3 has joined #epub 14:46:17 ack shiestyle 14:46:18 For the record I had that backwards--the Greek and Latin is on the verso and the English on the facing recto. 14:46:19 tzviya: who was the letter sent to? 14:46:27 George has joined #epub 14:46:37 shiestyle: Makoto headed up the letter 14:46:49 ... Ruby is based on HTML and CSS 14:46:50 zakim, next item 14:46:50 agendum 2 -- The Future of EPUB -- taken up [from wendyreid] 14:46:55 ... but maybe not a topic for epub 33 14:47:32 wendyreid: epub 33 will be the last revision that we intend to work on unless anyone makes a really convincing case for epub 34 14:47:57 ... we had a meeting yesterday called epub Next where we opened the floor to new feature requests, new business cases, etc. 14:48:01 q+ 14:48:10 George has joined #epub 14:48:36 ack ivan 14:48:38 ... as we wrap epub 33 there will be a year of testing, but work on the spec will be quieter. So we can take this time to start incubating new ideas for the future of digital publishing 14:49:00 ivan: any epub development is under a very strict constraint of backwards compat 14:49:38 ... an epub spec that breaks this backwards compat would cause serious industry backlash 14:50:10 George has joined #epub 14:50:11 ... we discussed many additional features for epub 33 - e.g. that content document must be strict XHTML 14:50:22 ... after much consideration we decided we could not change this now 14:50:49 janina: that makes sense, and kind of what I was imagining when I reviewed the fixed layout section 14:51:05 guests+ plh 14:52:10 George has joined #epub 14:52:22 jasonjgw has joined #epub 14:52:25 ... re. next gen: there was a suggestion that maybe instead of a building a bigger and better DOM, we iterate on what we have now and augment it for the use cases where it doesn't currently work well 14:52:45 George has joined #epub 14:52:53 ... e.g. in braille representation of music 14:52:56 q+ 14:53:18 q+ 14:53:26 I have to leave for another meeting. Thanks for the review, and the comments! 14:53:59 ... we might consult the wider community about nesting graphical structures (e.g. a way to drill down from a larger graphic to individual parts) 14:54:03 ack jasonjgw 14:54:10 George has joined #epub 14:54:47 jasonjgw: it was broadly recognized at that meeting earlier this week that diagrams and statistical charts all present a11y issues 14:55:27 ... but we're likely to encounter more of this in future digital media, once authors step away from print analog 14:55:42 q+ 14:55:45 ... in education, research, etc. 14:55:58 scribe+ 14:56:02 ack Fredrik 14:56:10 George has joined #epub 14:56:38 Fredrik: Nested graphics and objects - there is work going outside the w3c 14:57:01 present+ Jen_Goulden 14:57:04 ... part of working on braille, being done by American Printing House for the Blind (?) 14:57:41 ... This is still confidential, but they would be interesting in talking about a sub-standard for braille, that might become a basis for digital braille 14:58:09 ... They are also working on nested objects which have a lot of issues, they would be interested on working on that with us 14:58:10 George has joined #epub 14:58:26 q+ 14:58:35 janina: I think I know who might be involved 14:58:47 George has joined #epub 14:58:53 Fredrik: They have asked for this to flow through me, but I am a little out on thin ice 14:59:01 ack avneeshsingh 14:59:04 janina: I will look into this 14:59:09 q+ george 14:59:27 avneeshsingh: DAISY reviewed the APH work and has already provided feedback 14:59:28 George has joined #epub 15:00:20 avneeshsingh: Everything mentioned about nesting, etc, it doesn't look very epub specific 15:00:36 ... This seems more generally web related 15:00:43 ack tzviya 15:00:47 ... But epub should participate in that 15:00:57 tzviya: Agreed this is larger than what epub would take on 15:01:19 rrsagent, draft minutes 15:01:19 I have made the request to generate https://www.w3.org/2021/10/28-epub-minutes.html shadi 15:01:33 ... But as we advance epub, we are making it more weby, so we will avoid anything that moves us away from the web 15:01:52 ack George 15:01:57 ... If we are working on nested images or changing the DOM, then that has to be a broader project 15:02:10 George has joined #epub 15:02:18 George: Agree with Avneesh 15:02:44 ... I have been asked to do a presentation on advanced features in digital books and immersive reading in VR/AR 15:03:03 ... No idea what to say, other than we want to follow the web here for things that are proven accessible 15:03:10 George has joined #epub 15:03:41 janina: Hearing that ee can think of good things to have, but we wouldn't incubate and develop them in our group 15:04:10 George has joined #epub 15:04:21 George: We have heard that these documents are very important and need to retain the ability to open them in the future 15:04:40 present+ 15:04:42 janina: I think that was most of what I would want for epub 4 15:05:19 ... want to finish with a summary of what we are producing 15:05:48 ... Pronunciation is some immediate work that might be of value 15:06:09 wendyreid: When we talk about the future of publications, they don't need to be bleeding edge 15:06:10 George has joined #epub 15:06:21 ... we often hear that publishing is slow moving 15:06:37 ... epub 3 turned 10 this year, and we are still trying to convince people to adopt it 15:06:53 ... epub next is a long time horizon (years) 15:07:18 ... Some ideas may not be new, they may just be improvements, or they may be filling wholes in what can be done today 15:08:09 janina: Review of work on pronunciation 15:08:10 George has joined #epub 15:08:32 ... Paul would you do a review? 15:08:56 PaulG: Speech in HTML spec allows for aspects of SSML in HTML 15:09:36 ... We have a few proposals for brining in SSML and socializing with AT and browser vendors 15:09:50 q+ 15:09:55 ... Still figuring out which implementation to go with, then will go to FPWD 15:10:24 janina: This is work to get consistent pronunciation across implementations. Just for the tough spots, don't need it everywhere 15:10:38 PaulG: SSML brings a lot of options for full expression 15:10:53 ... We could do a full audio drama if we wanted with SSML 15:10:56 George has joined #epub 15:11:31 ... Trying to code the equivalent of a real world performer is tricky, but doable 15:11:43 ... Might be interesting for everyone 15:11:55 ack avneeshsingh 15:12:39 avneeshsingh: For this version of epub we are making sure we don't get in the way of this work 15:12:55 ... in the longer term we are working on a note to cover this topic 15:13:10 ... Once this is mature, it will come by default to RSes 15:13:21 ... It shouldn't require extra code for it 15:13:25 q+ 15:13:35 ... So we just need to make sure we don't break it with our work on epub 15:13:41 q+ 15:13:51 ... Once it is in CR, all we have to do is point to the spec 15:13:54 ack mgarrish 15:14:08 +1 to avneeshsingh 15:14:25 mgarrish: I didn't write that document! We wrote it, but no one came to the party 15:14:53 ... One of the reasons that note exists is it may be a blocker for epub 3.3 15:15:09 ... It isn't competing, we just need to put it in a box somewhere 15:15:14 ack wendyreid 15:15:23 ... But when this work comes out we will definitely move to the new way 15:15:45 wendyreid: One idealogical shift is, when there wasn't a tech available we just invented it 15:16:10 ... Without giving a thought to who would implement it. As part of W3C, we have to consider other groups 15:16:22 q+ 15:16:25 ack mgarrish 15:16:28 ... We can offer to help with our expertise, but should also rely on them for their expertise 15:17:00 mgarrish: Part of the reason the note exists is for backward compat, due to our compat requirements 15:17:11 ... We aren't trying to aggressively push it 15:17:28 q+ to ask about browser involvement 15:17:40 ack tzviya 15:17:40 tzviya, you wanted to ask about browser involvement 15:17:45 janina: A11y often takes a while to become real 15:18:15 tzviya: One issue we have had with epub when we haven't involved implementors along the way 15:18:30 ... The "when we spec it they will come" problem 15:18:52 ... Is there active involvement in the browser community for the APA work? 15:19:06 janina: Bad news - browsers are not in the task force 15:19:40 ... good news - when we had a joint talk with aria, it sounded like there were browser vendors who where interested 15:19:59 George: I attended a meeting last week with MS and the World Blind Union 15:20:14 ... Their read aloud tech would benefit tremendously from this work 15:20:22 q+ 15:20:33 ... read aloud is coming up more and more on discussions about neuro diversity 15:21:03 ... Read aloud is very important in these discussion, that would be a good reason to get this working in browsers 15:21:12 ack CharlesL 15:21:20 janina: Paul has pointed out that this can help PDAs do a better job 15:21:51 CharlesL: In that meeting it was mentioned there is a toolkit available for adding immersive reading 15:22:05 janina: Do we have any notes on that? 15:22:14 George: I will update after checking on it 15:22:52 janina: Personalization is nearer term - Charles? 15:22:58 CharlesL: Brief update 15:23:37 ... The spec for personalization allows content creators to add support for people with cognitize challenges 15:23:59 ... Personaliztion is farthest along 15:24:08 ... Can use it to add additional semantics 15:24:16 ... Goes further than aria roles 15:24:29 ... We have about 5 major areas in the module for actions 15:24:41 ... For example, clicking on buttons 15:24:56 ... There is also one for destination (where does this link take you?) 15:25:16 ... Purpose: helps understand what certain fields are 15:25:34 JenG has joined #epub 15:25:40 ... and one for simplification 15:25:53 Present+ 15:25:59 ... Symbols is one we might care about 15:26:13 ... Using symbols in place of words (?) 15:26:59 janina: Turns out there are plenty of people who don't deal well with a lot of text, but can handle it with some graphic signposts 15:27:29 ... Problem is meaning of graphics will depend on regional difference, etc 15:27:39 ... We are not adopting a universal symbol set 15:28:07 ... This is more important for interactive content, remains to be seen what it will mean for static content 15:28:12 ... And that's all! 15:28:20 PaulG has left #epub 15:28:21 present+ 15:28:25 wendyreid: Thanks everyone for feedback and reviews 15:28:33 Q+ 15:28:41 ack JenG 15:29:28 JenG: Wondering whether if we can arrange a quick chat with someone for help with participation 15:29:48 everyone: Yes please! 15:31:54 shadi has left #epub 15:31:59 CharlesL has left #epub 15:37:50 dkaplan3 has left #epub 15:47:05 duga has joined #epub 16:01:01 duga has joined #epub 16:17:08 mgarrish has joined #epub 16:26:57 Karen has joined #epub 16:29:22 rrsagent, draft minutes 16:29:22 I have made the request to generate https://www.w3.org/2021/10/28-epub-minutes.html ivan 16:31:46 zakim, end meeting 16:31:46 As of this point the attendees have been rickj, wendyreid, janina, dauwhe_, tzviya, shadi, BenSchroeter, SamKanta, CharlesL, MattChan, shiestyle, JF, duga, ivan, George, PaulG, 16:31:49 ... jasonjgw, victoria, roy, John, Roque, becky, bkardell_, avneeshsingh, FredrikFischer, AndrewNevins, anevins__, Fredrik, Jen_Goulden, JenG, dkaplan 16:31:49 RRSAgent, please draft minutes 16:31:49 I have made the request to generate https://www.w3.org/2021/10/28-epub-minutes.html Zakim 16:31:51 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 16:31:53 rrsagent, bye 16:31:53 I see no action items 23:13:46 RRSAgent has joined #epub 23:13:46 logging to https://www.w3.org/2021/10/28-epub-irc 23:13:47 RRSAgent, make logs Public 23:13:48 please title this meeting ("meeting: ..."), wendyreid 23:14:06 meeting: EPUB 3 WG TPAC Face to Face Meeting Day 1 23:14:14 date: 2021-10-28 23:14:29 chair: wendyreid, dauwhe_ 23:15:06 agenda+ Welcome and goals 23:15:13 agenda+ Virtual Locators 23:15:23 agenda+ Flow Control 23:15:38 agenda+ Horizontal Review - PING 23:15:56 agenda+ Outcomes of the EPUB next meeting 23:36:33 dauwhe has joined #epub 23:49:28 toshiakikoike has joined #epub 23:51:24 present+ 23:53:58 present+ 23:56:21 present+ 23:58:41 present+ 23:58:46 present+ 23:59:14 dkaplan3 has joined #epub 23:59:18 MattChan has joined #epub 23:59:48 BenSchroeter has joined #epub 23:59:55 MasakazuKitahara has joined #epub 00:00:00 present+ 00:00:01 present+ 00:00:06 present+ 00:00:08 CharlesL has joined #epub 00:00:18 present+ 00:00:47 duga has joined #epub 00:01:01 present+ 00:01:38 John_Roque has joined #epub 00:01:53 scribe+ 00:01:58 Victor_Lopes has joined #epub 00:02:11 zakim, next item 00:02:11 agendum 1 -- Welcome and goals -- taken up [from wendyreid] 00:02:20 scribe+ 00:02:36 present+ 00:02:45 present+ John Roque 00:03:21 present+ 00:03:34 myles has joined #epub 00:03:41 present+ myles 00:04:09 Hadrien has joined #epub 00:04:18 present+ 00:04:21 victoria has joined #epub 00:04:40 wendyreid: welcome to the virtual face-to-face - there are a couple of items on the agenda for tonight 00:05:16 wendyreid: we are working to CR - have done horizontal reviews - approved by i18n and a11y - working on ping at tag 00:05:36 dlazin has joined #epub 00:05:52 wendyreid: we'll be looking at issues and also task forces over next two days 00:06:17 wendyreid: we are also going to look at testing - how to get more tests done and get to finish line 00:06:47 zakim, next item 00:06:47 agendum 2 -- Virtual Locators -- taken up [from wendyreid] 00:07:41 https://w3c.github.io/epub-specs/epub33/locators/ 00:07:58 BenSchroeter: we formed this group to banty about the perception that digital publications we slow on uptake and epub needed a way to locate things across digital environments 00:08:52 BenSchroeter: we're sort of solving old problems again - we got a group of indexers and reading system people and looked at cfis for pointing to particular spot 00:09:51 BenSchroeter: after figuring out use cases and whittling them down we wanted to be able to do index references and citations that work across the ecosystem 00:10:48 BenSchroeter: we're finding there isn't always a print equivalent for epubs so publishers make up page lists 00:11:16 BenSchroeter: would be useful to align so that reading systems can define the same pagination - what recommendations can we give 00:11:36 BenSchroeter: we're currently developing best practices for how to cite or locate a spot in an ebook 00:12:26 q? 00:12:39 wendyreid: the order of operation is that publishers provide the page list - that is the best possible scenario - in the absence of that this algorithm can provide a good experience platform to platform 00:12:55 q+ 00:13:01 wendyreid: a lot of affordances currently cannot be done because there isn't a page list 00:13:05 ack CharlesL 00:14:02 CharlesL: this has been brought up with us recently that publishers always have page breaks - we're going to require GCA partners put page numbers in 00:14:32 CharlesL: it would be good if publishers use these recommendations to put pagination in, not just for reading systems to use 00:15:17 wendyreid: we're not going to state that this is only for reading systems - could be used for tools that produce digital only works or the print version no longer exists 00:15:31 q+ 00:15:43 wendyreid: important part is that it is always done the same way 00:16:02 q+ 00:16:14 ack duga 00:16:16 q+ 00:16:46 q? 00:17:00 duga: also works as a threat that if you don't do the pagination we'll do it for you in ways that may not be ideal in all cases 00:17:13 ack BenSchroeter 00:18:03 ack dlazin 00:18:05 BenSchroeter: having others beyond me say this is important is really helpful in getting this in publications - good to have these consequences to show people 00:18:50 q+ 00:18:56 dlazin: the ideal scenario is that the algorithm is never used - we would rather page numbers than an algorithm - meant as a fallback 00:18:59 q+ 00:19:03 ack BenSchroeter 00:19:23 q+ 00:19:25 BenSchroeter: the guidance is going to be really helpful to publishers to understand where to put their page numbers 00:19:25 ack Hadrien 00:19:58 ack CharlesL 00:20:02 Hadrien: I think page lists are good in theory more than practice - the fact you can use a string and they are not exhaustive doesn't help reading systems 00:20:49 q+ 00:21:33 ack Hadrien 00:21:34 CharlesL: for accessibility and academic space having page breaks and being able to jump to the spots is important - there may be issues we need to address but is helpful 00:22:10 Hadrien: not arguing the use cases but the technology is not great right now - it is easy to write a page number that is not useful 00:22:21 q+ 00:22:26 ack shiestyle 00:23:15 shiestyle: when thinking about web toons in japan they consist of very long images and we have to separate the images and be able to index inside the image - a new use case for virtual locators 00:23:48 q? 00:23:58 wendyreid: we have talked a little bit about scrolled content because we know all content is not paged but we should be able to get a list of locations in any type of scrolled document 00:24:05 q+ 00:24:10 ack dauwhe 00:24:36 q+ 00:25:09 ack dlazin 00:25:10 dauwhe: what suggestions do people have to avoid the problems of using strings - print equivalents come in lots of formats with lots of different numbering systems - sounds like a user interface problem 00:26:35 q+ 00:26:50 q+ 00:26:53 dlazin: to my mind strings as page numbers is not critical as you can still arrive at the page you want but typing it - if you stick to conventions it's not too bad 00:26:55 ack duga 00:27:15 q+ 00:27:50 duga: not sure it's a terrible impossible UI problem - having users choose from a small list will allow them to determine if they're entering wrong info - we haven't had a big problem with this - more problematic is when publishers do not provide a full list of pages 00:27:54 ack CharlesL 00:28:40 CharlesL: you could scrub the data - use a slider to move around instead of typing in - knowing how far you are in is another important use case for pages 00:28:45 ack Hadrien 00:31:06 Hadrien: listing the type of affordances built on top of pagination is important - displaying the page number while reading is one and is easy enough as the value doesn't matter - a progression is another but here page numbers get confusing if they are not numeric - another is jumping somewhere which is sometimes a dedicated affordance or sometimes in search and here strings are problematic too 00:31:06 - augmenting existing content via annotations is a last one and string or no string is not a big issue - navigating content is the big issue when you don't have controlled values 00:31:25 q+ 00:31:40 ack wendyreid 00:31:41 - it helps to understand all these and what we need 00:32:52 q+ 00:33:02 q+ 00:33:54 wendyreid: another case where the reality is we cannot enforce a scheme on everyone - we can make strong recommendations like using a consistent and understandable scheme to it - for example, use only numbers - very common to have roman numerals for front matter and numbers starting from 1 in body - so long as it is consistent it helps the user 00:33:59 q? 00:34:16 wendyreid: having good UI can ameliorate the problem 00:34:16 ack CharlesL 00:34:39 q+ 00:35:00 ack BenSchroeter 00:35:01 CharlesL: ordering doesn't matter so much as being able to get to a specific page - missing pages and blank pages are another issue we need to address 00:35:52 BenSchroeter: whatever the epub implementation is it has to accommodate being faithful to the print equivalent - it has to accommodate what is print otherwise we have to change what print does 00:35:52 ack duga 00:37:10 q+ 00:37:13 duga: I think ordering is important because the pagination is powerful and important in determining how big ranges are - can we get people to stop using roman numerals as they're really annoying 00:37:14 ack Hadrien 00:38:55 Hadrien: given that we allow people to do messy things reading systems will always encounter epubs with missing info - by allowing what we allow will only make them useful for context - reading systems won't be able to adopt this because the method isn't consistent and there is too much existing content without 00:40:57 wendyreid: the unknown quantity is there is a desire from users that pushes reading systems to provide this - if we can demonstrate there is a tangible value to providing consistent locations by showing the affordances it helps make the case for publishers to make this change 00:42:00 wendyreid: the task force meets every two weeks for those who are interested - meet at different times to accommodate different regions - I will send out a refresh about meetings after TPAC 00:42:18 wendyreid: we can continue to work on this after epub goes to CR 00:42:36 zakim, next item 00:42:36 agendum 3 -- Flow Control -- taken up [from wendyreid] 00:42:59 https://github.com/w3c/epub-specs/issues/1378 00:43:50 dauwhe: this issue originally came from Ivan that we have rendering properties for authors to express if content is paginated or scrolled 00:44:33 dauwhe: we have two types of scrolled - one continuous one where all documents scroll and scrolled-doc where each document scrolls but you transition between them 00:44:50 dauwhe: you can set these globally for all spine items and also override them per spine item 00:45:18 dauwhe: I believe this was clarified in the issue discussion but there was some appetite to have better images and descriptions of this in the spec 00:45:42 dauwhe: the larger point is how do these things interact with synthetic spreads and that gets complicated 00:46:10 mgarrish: That sounds generally correct 00:46:33 ... The interactions between these fixed layout properties are confusing 00:46:52 ... We (probably) originally envisioned them as global 00:47:07 q+ 00:47:09 q+ 00:47:12 ... We aren't even sure if this even work (eg scrolled) 00:47:17 ack dauwhe 00:47:24 q+ 00:47:35 dauwhe: do all the possible combinations of these properties make sense 00:47:39 ack had 00:49:11 Hadrien: it's worth pointing out that scrolled continuous is not the most implemented feature - it is difficult to implement - it is a useful feature for certain types of publications but it's questionable whether the author or the user should control - web toons are an example of where it gets tricky on how to control as the author intent is arguably more important 00:49:13 ack shie 00:49:54 shiestyle: in Japan we need scrolled continuous for web toons and Apple reading system handles it - I don't know any use cases for scrolled-doc 00:49:55 q+ 00:50:02 ack dauwhe 00:50:48 q+ 00:50:51 ack Hadrien 00:50:52 ack ha 00:50:52 dauwhe: I wonder if this is a case for writing a grid of test possibilities and see what happens - maybe this will reveal what makes sense and what doesn't and what has actually been implemented 00:51:22 q+ 00:52:26 ack wen 00:52:27 Hadrien: aside from web toons is manga let user decide if they want to use spreads or paginated view or scrolled continuous - not something the content needs except for web toons - also used as an easy way of reading manga - need to distinguish author and user preference and that's where our issue is - if it is important it shouldn't be overridden 00:52:43 q+ 00:53:45 q+ 00:54:07 q+ 00:54:12 wendyreid: this falls into the same category of potential spec overreach as the fxl orientation properties - we had good intentions in providing the option for authors to specify landscape orientation but user choice comes above all else - whatever the user wants to do should is paramount 00:54:27 wendyreid: do we need all these options? 00:54:27 ack dau 00:55:36 ack ch 00:55:40 dauwhe: I have seen interesting uses of odd combinations of the properties - some educational material uses synthetic spreads to put a graphical page on one side and a scrolling doc in the other side so they can read about the graphic while still being able to view it - not sure I want to lose possibilities 00:56:32 CharlesL: with orientation you can't force displays as it affects the accessibility of the document - user needs to be able to override 00:56:34 ack dl 00:56:54 https://github.com/w3c/epub-specs/blob/main/epub33/explainers/EPUB33-explainer.md 00:57:41 q+ 00:58:28 ack ho 00:58:29 dlazin: Dave wrote a nice summary of what epub is for the tag - that reading systems have tended to give preference to users should also be in it - there is still a lot of disagreement about what epub is and should be so we should try to agree on what the fundamental difference is between epub, html and pdf 00:59:23 hober: you said users come first in epub but that's also the priority of constituents on the web 00:59:56 q+ 01:00:14 dkaplan31 has joined #epub 01:00:29 q+ 01:01:02 ack dau 01:01:02 hober: you're saying that web page rendered in browsers implement their own UI while epubs rely on reading system chrome - browser UI provides similar control but not akin to applications 01:01:26 gotta go do bedtime now, bye for a while! 01:01:47 dauwhe: when I author an epub I do not provide a way to change fonts or move page to page - completely dependent on reading system UI - when I make a web page I decide how it works 01:01:49 ack Had 01:02:27 q+ 01:02:34 q+ 01:02:37 Hadrien: even when the user doesn't override any setting the reading system injects a lot of script and styling - quite different from web in that regard 01:03:05 q+ 01:03:09 Hadrien: always in constant negotiation between what the publisher wants, what the reading system has to do, and what the user wants 01:04:07 dauwhe: it doesn't feel like we're reaching a resolution on the issue - I think testing is key here to figuring out what we support 01:04:09 ack ho 01:04:10 q+ 01:04:13 ack dau 01:04:22 dkaplan3 has joined #epub 01:04:56 dkaplan32 has joined #epub 01:05:05 hober: another example of browsers doing invasive things by default on behalf of users is text auto-sizing on mobile browsers - very complicated and invasive and has lots of effects on page that the author doesn't intend but the user wants 01:05:08 ack shie 01:06:57 shiestyle: I agree user should be able to select rendering - for web toons we have to put in this property otherwise the images are not connected smoothly - maybe we could use new metadata for web toons or discuss another solution 01:07:01 ack ch 01:07:24 CharlesL: for a scrolled doc couldn't we mark it at-risk if we don't have implementations? 01:07:51 q? 01:07:51 dauwhe: yes, that's what we want to find out but we can't make them at-risk in advance of knowing - also have to make sure we don't break existing epubw 01:08:01 s/epubw/epubs/ 01:08:19 q+ 01:08:24 ack ha 01:09:43 Hadrien: one last note to say that we're in the middle of implementing this in readium - presentation API to combine these things together and figure out what gets precedence - it is pretty complex in fxl but user settings in general also are - adding any feature requires figuring out all the interaction and we haven't always done that in the past 01:10:17 dauwhe: if there is anything in the spec that doesn't make sense please open issues 01:11:00 01:12:17 agenda? 01:14:20 zakim, next 01:14:20 I don't understand 'next', wendyreid 01:14:24 zakim, next item 01:14:24 agendum 4 -- Horizontal Review - PING -- taken up [from wendyreid] 01:18:44 s/web toon/webtoon/ 01:21:09 scribe+ 01:21:34 TOPIC: privacy 01:22:41 dauwhe: we met with the privacy group about horizontal review 01:23:00 ...worked through a list of items they found in our spec 01:23:30 ...we broke that list up into discrete issues 01:23:33 https://github.com/w3c/epub-specs/issues/1871 01:24:26 ...if an ebook links out to the web, is there danger of passing user's personal information? 01:25:25 q+ 01:25:31 ack dug 01:25:38 ...we make assumptions as to what user agent does when a link is activated 01:25:46 q+ 01:26:27 duga: presumably the website you go to would know where you are coming from and what book you are reading 01:26:40 ...it's an inherent danger of using the web 01:27:07 ack mg 01:27:14 dauwhe: no different than a link from anywhere - not peculiar to EPUB 01:27:14 q+ 01:27:35 q+ 01:27:44 q+ 01:27:49 mgarrish: these dangers are not just for ebooks 01:28:37 ack cha 01:28:47 ...what can we really say about this other than making it clear? it's beyond our control. how do we enforce it? don't know where this fits in the spec 01:28:58 q+ 01:29:17 CharlesL: we don't have control over what the user agent does 01:29:23 q+ 01:29:38 ack du 01:29:41 q- 01:29:48 ...I think they want some sort of disclaimer that there is nothing in the spec that prevents passing personal info when you follow a link 01:30:45 ack mg 01:30:56 duga: scripting is harder for the user to understand, but link following is a user action and user's should accespt the inherent danger. not sure what we can do in the spec for either but they are separate issues 01:31:48 mgarrish: browsers can spy on you too, so this is no different than any other privacy concerns for the web 01:32:16 q+ 01:32:18 ack wen 01:32:33 ...don't know how we can solve this in any meaningful way 01:33:14 Roy_ has joined #epub 01:33:52 wendyreid: we should probably try to write a privacy statement for EPUB. it will likely not be normative. it would be a useful practice for us to outline these things. Reading systems do have privacy frameworks to adhere to. 01:34:22 q? 01:34:33 ack ho 01:34:48 ...we can advise reading systems on privacy best practices, but I'm not sure we can or should make normative statements 01:36:03 q+ 01:36:39 ack ch 01:36:54 hober: these are good things to include in a privacy consideration section - there is a cascade of different actors that can do hijinks if you do certain actions that may not be intended by author or user 01:37:05 q+ 01:37:52 CharlesL: audience for our documentation is mostly publishers; this might be useful information to them 01:37:54 ack du 01:38:49 q? 01:38:50 duga: this section would be important for RS developers too, like what security models to follow under different circumstances 01:39:03 https://github.com/w3c/epub-specs/issues/1872 01:40:24 dlazin has joined #epub 01:40:27 dauwhe: other things they brought up - user agent strings, trying to figure out what RS was in use 01:40:46 ...are people giving accurate user agent strings? 01:41:17 https://www.computer.org/csdl/proceedings-article/sp/2021/893400a247/1mbmHAQitna 01:42:06 wendyreid: link to security review of EPUBs, behind a IEEE paywall 01:43:56 https://github.com/w3c/epub-specs/issues/1873 01:43:58 dauwhe: we need to look into user agent strings and how much information is in them for PING 01:44:07 ...that will be homework. 01:44:24 ...another thing PING brought up: obfuscation 01:45:03 q+ 01:45:07 ack mg 01:45:46 mgarrish: it would be nice if we didn't have this, but now that we're 10 years in, not sure what we cann do about it 01:46:04 ...we're kind of stuck with it 01:46:07 q+ 01:46:13 ack du 01:46:17 there is a SHOULD that should be a MUST 01:46:30 ...we can point out that it is trivial 01:47:10 duga: we can't remove it; we could recommend using WOFF 01:47:11 WOFF 01:48:10 hober: clarification on obfuscation? 01:48:16 q+ 01:48:36 dauwhe: how to keep fonts from escaping the EPUB to protect font vendors 01:49:26 https://w3c.github.io/epub-specs/epub33/core/#sec-resource-obfuscation 01:49:33 ack dl 01:50:48 dlazin: keeping in mind that Adobe is a main exporter of custom ebooks, they have had a strong interest in both DRM and protecting their fonts 01:50:52 q? 01:51:01 q+ 01:51:46 ...if you take an InDesign ebook and change the publication ID, the font will no longer work because it is ties to that hash 01:51:58 ack d 01:51:59 https://github.com/w3c/epub-specs/issues/1874 01:52:12 q+ 01:52:16 dauwhe: TOPIC: DRM 01:52:21 ack we 01:52:38 ...what are the privacy concers with DRM and how can they be mitigated: 01:53:44 wendyreid: a concern they raised was that the user can't view source of an EPUB with DRM in the reading system like they can elsewhere on the web 01:54:05 q+ 01:54:12 ...we don't have a good way to address this because it manifests because of business reasons 01:54:31 ack du 01:54:46 dauwhe: also not sure why privacy mitigation is to view source of complex computer files 01:55:20 q+ 01:55:36 q+ 01:55:38 q+ 01:55:41 duga: we can take the DRM stuff out of the spec but it will have no effect on the world. Many reading systems don't use conventional DRM schemes 01:56:00 q+ 01:56:16 https://github.com/w3c/epub-tests/pull/21/files#diff-ce665722f33ccf90b768b5d51b4ed355aadb015ffd3bfe4a82dafaad37b4bb17 01:56:19 ...it's more a political than a practical issue. We could move it from the spec or a note. 01:56:39 dauwhe: but obfuscation relies on encription.xml 01:56:51 q+ 01:56:52 ack dl 01:56:58 ack dau 01:57:14 ack dk 01:57:22 dlazin: echoing that obfuscation uses encription.xml 01:58:11 dkaplan32: if we punt on the political issue, then we can't talk about accessibility in DRM, which is a big problem 01:58:15 ack ho 01:59:11 s/dkaplan32/dkaplan3/ 01:59:17 q+ 01:59:26 ack mg 01:59:36 hober: primary purpose for spec is interoperability and primary audience is implementors. Not sure we are doing them any favors by removing this from the spec. Would rather acknowledge this 02:00:18 mgarrish: encription.xml is a W3C thing, so it would be weird to throw it out. we should let it slide. 02:01:13 q+ 02:01:25 ack da 02:01:26 ack dl 02:01:45 dauwhe: there is an open source spec for EPUB designed for interoperability with DRM - DRM is imprtant for library lending of eBooks too. I think I'm supportive of not backing away from our modest provisions to acknowledge how this technology is used in the real world. 02:02:05 dlazin: is encription.xml used in libraries? 02:02:11 duga: yes 02:02:14 q? 02:02:46 dlazin: so EPUB provides one way to provide DRM, but reading systems use their own anyway? 02:03:29 ...there are other ways to talk about encription. Should we explore alternate ways to talk about obfuscation and DRM? 02:03:32 q? 02:04:22 q+ 02:04:25 ...other purpose of the spec is to write down how stuff works. 02:04:47 ack mgarrish 02:04:48 ack mg 02:04:58 q+ 02:04:59 mgarrish: do authors ever author in encription.xml? 02:05:27 q+ 02:06:02 ack duga 02:06:20 ack ho 02:06:33 dauwhe: it was always intended that reading systems would implement the DRM 02:07:18 q+ 02:07:21 hober: the document has authoring requirements that the tools that generate it need to follow 02:07:24 ack dl 02:08:48 wendyreid: we need to do some more investigation about this. Per our charter, DRM is supposed to be out of scope, but we also need to respond to horizontal review. 02:09:14 https://w3c.github.io/epub-specs/epub33/core/#sec-container-metainf-encryption.xml 02:09:44 q+ 02:10:02 q+ 02:10:03 dlazin: what section of the spec are we talking about? DRM is out of scope because it is not cross-compatible. 02:10:09 q+ 02:11:03 ack da 02:11:25 dauwhe: intention was that you could buy an EPUB from one retailer and use it in another - but that never materialized 02:12:15 duga: you can from GooglePlay Books even though it is DRM protected using Adobe 02:13:04 wendyreid: Adobe DRM - you can download and sideload and share limited times but it authenticates everything (and breaks often) 02:13:07 ack ben 02:13:18 q- 02:13:24 q? 02:15:36 q+ 02:16:54 ack da 02:22:48 02:34:46 scribe+ 02:34:57 zakim, next item 02:34:57 agendum 5 -- Outcomes of the EPUB next meeting -- taken up [from wendyreid] 02:35:45 q+ 02:35:46 wendyreid: We had the epub next meeting on Wednesday. Discussed what happens next (ie after epub rec) 02:36:23 ... There is some interesting discussion on the email thread for the minutes of that meeting 02:36:23 ack BenSchroeter 02:37:06 q? 02:37:07 BenSchroeter: This is riffing of a Twitter discussion: if we could figured out the backwards compat problem it might open the door for imaginative improvements 02:37:39 ... So we would look at what it would mean to support the current ecosystem while also looking at a new format 02:38:43 wendyreid: This is based on a personal statement, but if we don't rethink backwards compat (very strict - any published book is still valid epub 3.3) it will be hard to move forward 02:38:53 q+ 02:39:32 ... Does that mean a file created today must work on every legacy system? Or does it mean we work in the same tech space (webby), but advance beyond where we are 02:39:33 ack dauwhe 02:39:54 q+ 02:39:59 dauwhe: We have been unable to make some changes even though they are backward compat 02:40:19 ... For instance the html serialization wouldn't break existing content 02:40:27 q+ 02:40:32 ... but we can't do for other ecosystem reasons 02:41:05 ack dkaplan 02:41:06 ... We are really constrained because we can't even make epubcheck emit warnings 02:41:47 dkaplan32: We don't expect anyone else to follow a similar backwards compat constraint (eg no one else in the W3C does this) 02:41:56 ... The web just doesn't do this 02:41:59 ack shiestyle 02:42:43 q+ 02:42:51 shiestyle: The most important thing the Japanese community needs is sustainability and interoperability of epub 02:43:09 ... A lot of the epubs made there are hand generated and were very costly to produce 02:43:15 ack hober 02:43:17 q+ 02:44:09 hober: When we talk about compat in the web, we are talking about the corpus of the web 02:44:25 ... but interop and compat are different 02:44:40 q+ 02:44:44 q+ 02:44:58 q+ 02:45:04 ... The constraint of any new book being openable in older readers may tie your hands 02:45:29 ... It make sense to align with the way the web works (old content can still be opened, but new content needs new readers) 02:45:30 hober++, existing pubs should continue to work in new readers, new books shouldn't necessary work in old readers. 02:45:48 ack dlazin 02:45:55 ... But also understand that books are a little different than the web (I bought a book, but not a web page) 02:45:58 +100 hober 02:46:16 dlazin: We don't have 100% fidelity today, so we can't guarantee it for the past 02:46:41 ... Is there a way to have a graceful degradation mode? 02:46:58 q+ 02:47:14 ... We don't really need 100% fidelity, we could get by with a poorer display (eg text is still available) 02:47:43 ... Q: How do living specs work? How does the web survive with ever changing specs and we can't? 02:48:37 hober: Web pages aren't modal. So we don't say "this is xhtml 1.0, and you must render it that way or not at all" 02:48:47 ... everything just goes through the same path (roughly) 02:48:49 q+ 02:48:58 q- 02:49:10 ... The web does it with strong guards to not make breaking changes in the living specs 02:50:03 ... HTMLparser was a reverse engineering effort to standardize html parsing across browsers 02:50:38 ... For years isindex was in that, even though it was terrible 02:50:57 ... But we were finally able to remove it because it was barely used on the internet 02:51:28 ... Basically we manage living starts with a strong social contract not to break things 02:51:48 ... But that means there are ways we can't change the internet in certain ways 02:52:19 ... But modes are bad. Whenever there is a mode switch, we introduced lots of problems and had regrets 02:52:25 q+ 02:52:27 ack CharlesL 02:52:39 CharlesL: Can't we just start over? 02:52:59 ... Take what we have learned and make an epub-like system that is in line with the web 02:53:27 ... It would be completely new and different 02:53:50 mgarrish: Maybe one thing we got right with pub manifest was the migration path 02:54:01 ... You could go between the two 02:54:16 ack mgarrish 02:54:29 ... We probably need to be able to improve in what we have. So long as there is a migration path we are good 02:54:52 ... At least it provides a continuation 02:54:53 ack mg 02:55:41 wendyreid: The publishing WG came at a bad time, but the path to something new has been laid 02:56:08 ... The book I bought 5 years ok should still work forever 02:57:03 ... So maybe part of the book fails (eg package) but the content still works because it is just html 02:57:17 ... Do we want epub to be an interchange format or a display format? 02:57:29 ... epub 2 and 3 got caught in both 02:57:54 ... Now we are time-boxed with the intention of being archivable 02:57:56 ack myles 02:57:59 ack wendyreid 02:58:25 myles: Tess described a situation where an old feature was removed 02:58:43 ... This wasn't just mechanical, it was a big deal 02:59:02 ... The usage being low isn't sufficient to remove (though probably necessary) 02:59:13 ... The web is very conservative about removal 02:59:27 ... second, the example was about old content in new browsers 02:59:39 q+ 02:59:42 q- 02:59:49 ... But the inverse is also required (new content in old browsers) 03:00:17 ... Ruby is a good example. Ruby text is still visible in an old browser that doesn't support it 03:00:55 ... We even added the ability for an old browser to style specially (eg with parens), that wouldn't happen in the new browser 03:01:02 q+ 03:01:04 ack duga 03:01:04 ... So we care about both directions 03:01:10 scribe+ 03:01:28 duga: A lot has been said. First off, the idea of a new break and starting over 03:01:35 ... feels a lot like modes 03:01:43 ... but like Tess said, bad idea 03:01:49 ... I'm worried about trying to do that 03:02:02 ... if we do need a break, we need to create something where we don't have this problem again 03:02:13 ... the features we have used, we are stuck with 03:02:17 ... books live a long time 03:02:31 ... maybe we want to move away from archiving, and just be for display, maybe? 03:02:41 q+ 03:02:44 ... I'm reluctant to move away from the things we used. 03:02:59 ... Does removing a feature mean that we no longer sell a book? 03:03:10 ... are we going to have this same problem with a new spec 03:03:15 ... 10 years into that 03:03:30 ... I'm not saying it's a bad idea, but are we opening a horrible modes can of worms 03:03:32 ack mgarrish 03:03:58 mgarrish: If we make a break and start over, we get away from having to do it all ourselves 03:04:24 ... If we work with what works on the web as much as we can, then we don't get stuck with bad old features 03:04:55 ... When we look at what comes next, the biggest issue is the xml serialization of the package document 03:04:59 zakim, close the queue 03:04:59 ok, wendyreid, the speaker queue is closed 03:05:33 ack dauwhe 03:05:42 ... What is the long term impact of staying in the html world? 03:05:51 https://twitter.com/dauwhe/status/1149681148957745152 03:05:57 dauwhe: Nothing technical is stopping us from putting books on the web 03:06:16 ... There is plenty of room for experimenting directly on the web 03:06:36 wendyreid: We are over time! But thanks all, wish we had more time to discuss it 03:07:01 ... See you all in eleven hours! 03:07:32 zakim, end meeting 03:07:32 As of this point the attendees have been dauwhe, wendyreid, toshiakikoike, mgarrish, shiestyle, MasakazuKitahara, dkaplan, MattChan, CharlesL, duga, BenSchroeter, John, Roque, 03:07:35 ... hober, myles, Hadrien 03:07:35 RRSAgent, please draft minutes 03:07:35 I have made the request to generate https://www.w3.org/2021/10/28-epub-minutes.html Zakim 03:07:37 I am happy to have been of service, dauwhe; please remember to excuse RRSAgent. Goodbye 03:07:41 Zakim has left #epub 03:09:02 CharlesL has left #epub 03:09:39 There's just 2 meetings in one 03:09:53 ah, good. I just saw the first part 03:10:00 Yeah, we're good 03:10:28 See you in 10 hours and 50 mins! 03:10:47 I'm going to go for a walk and try to unwind 03:30:23 duga has joined #epub 03:30:42 dauwhe has joined #epub 03:36:05 dauwhe has joined #epub 03:49:24 dauwhe has joined #epub 04:01:11 duga has joined #epub 04:20:00 duga has joined #epub 04:22:47 dauwhe has joined #epub 04:40:23 dauwhe has joined #epub 04:49:09 duga has joined #epub 04:57:23 dauwhe has joined #epub 05:19:16 dauwhe has joined #epub 05:44:06 dauwhe has joined #epub 05:46:52 duga has joined #epub 07:18:15 dauwhe has joined #epub 07:36:34 dauwhe has joined #epub 08:02:05 dauwhe has joined #epub 08:19:22 dauwhe has joined #epub 08:38:15 dauwhe has joined #epub 09:21:54 dauwhe has joined #epub 09:54:00 dauwhe has joined #epub 10:51:00 join_subline has joined #epub 11:04:31 join_subline has joined #epub 11:09:17 dauwhe has joined #epub 11:20:13 dauwhe has joined #epub 11:55:29 dauwhe has joined #epub 12:03:17 dauwhe has joined #epub 12:06:19 dauwhe has joined #epub 12:20:17 dauwhe has joined #epub 12:20:44 dauwhe has joined #epub 12:32:48 janina has left #epub 12:37:30 dauwhe has joined #epub 12:55:53 dauwhe has joined #epub 13:00:24 dkaplan3 has joined #epub 13:03:48 Karen has joined #epub 13:03:51 tzviya has joined #epub 13:05:44 dauwhe has joined #epub 13:15:43 mgarrish has joined #epub 13:16:10 dauwhe has joined #epub 13:20:48 dauwhe has joined #epub 13:25:35 dauwhe has joined #epub 13:28:52 dauwhe has joined #epub 13:33:49 CharlesL has joined #epub 13:33:53 kirkwood has joined #epub 13:37:13 dauwhe has joined #epub 13:42:27 Karen has joined #epub 13:49:04 duga has joined #epub 13:53:03 ivan has joined #epub 13:53:29 rickj has joined #epub 13:53:46 Zakim has joined #epub 13:53:54 zakim, start meeting 13:53:54 RRSAgent, make logs Public 13:53:55 please title this meeting ("meeting: ..."), ivan 13:54:32 Meeting: EPUB 3 WG TPAC Face to Face Meeting Day 2 13:54:49 present+ 13:54:52 Agenda: https://www.w3.org/events/meetings/a1c8ce2e-f205-451f-a6b5-3a41438bcebc 13:55:12 toshiakikoike has joined #epub 13:55:14 avneeshsingh has joined #epub 13:55:24 agenda+ FXL Accessibility 13:55:35 present+ 13:55:52 agenda+ The Mystery of the URIs 13:56:03 agenda+ Testing Update and Discussion 13:56:18 agenda+ Horizontal Reviews - Accessibility 13:56:40 present+ 13:56:50 present+ 13:57:22 present+ 13:57:32 shiestyle has joined #epub 13:57:37 guests+ shadi 13:57:41 present+ 13:57:46 present_ 13:57:50 present+ 13:58:17 present+ 13:58:22 present+ rickj 13:59:01 BenSchroeter has joined #epub 13:59:26 MasakazuKitahara has joined #epub 13:59:31 present+ 13:59:35 MattChan has joined #epub 13:59:36 Yanni has joined #epub 13:59:40 present+ 13:59:45 present+ MasakazuKitahara 13:59:58 present+ 14:00:01 present+ 14:00:15 present+ 14:00:21 present+ 14:00:50 present+ 14:00:51 present+ 14:01:06 guests+ jeng 14:01:33 present+ ubbink 14:01:49 present+ 14:01:52 Jemma has joined #epub 14:02:09 present+ CharlesL 14:02:17 guests+ jeff 14:02:21 scribe+ 14:02:26 wendyreid: good day, everyone 14:02:43 romain has joined #epub 14:02:43 present John Roque 14:02:43 jeff has joined #epub 14:02:46 ... good meeting last night 14:02:47 dlazin has joined #epub 14:02:50 present+ 14:02:51 gpellegrino has joined #epub 14:02:52 present+ John_Roque 14:02:53 present+ 14:02:55 JenG has joined #epub 14:02:56 zakim, next item 14:02:56 agendum 1 -- FXL Accessibility -- taken up [from wendyreid] 14:03:04 Present+ 14:03:04 present+ 14:03:08 .., let's talk about the FXL a11y task force 14:03:11 Aimee_U has joined #epub 14:03:17 present+ george 14:03:19 ... putting together a guidance doc for publishers 14:03:20 present+ 14:03:21 present+ 14:03:23 https://w3c.github.io/epub-specs/epub33/fxl-a11y/ 14:03:25 ... about how to build better FXL books 14:03:35 present+ makoto 14:03:38 George has joined #epub 14:03:42 ... this is best practices, things we've learned over the years. 14:03:45 present+ 14:03:50 ... they won't be perfect but they can be better 14:03:56 MURATA has joined #epub 14:03:57 present+ victoria 14:03:58 present+ 14:04:10 ... the doc is incomplete and a work in progress 14:04:17 ... we talk about reading order, alt text, navigation 14:04:18 George has joined #epub 14:04:22 laurent_ has joined #epub 14:04:24 ... there will be a section on legibility 14:04:31 ... a11y metadata, tables... 14:04:34 present+ laurent 14:04:39 ... we want to build some examples 14:04:42 ... with real content 14:04:53 George has joined #epub 14:04:55 ... showing it's possible to make accessible complex fixed layout content 14:05:02 ... the other thing is that we've been working with 14:05:16 ... we still can't make FXL completely accessible 14:05:22 ... a big problem is low-vision users 14:05:28 guests+ Louis_Maher 14:05:28 present+ laurent 14:05:28 present+ hober 14:05:42 ... if you can't increase the font size effectively, that use case just doesn't work. 14:05:51 present+ dlazin 14:05:57 ... this is where we're looking for ideas. It's experimental. 14:06:01 ... we have two proposals. 14:06:13 ... we've struggled to name it 14:06:18 ... visual/textual affordance 14:06:24 ... can we develop a way in EPUB 14:06:40 George has joined #epub 14:06:44 ... for a content creator let the reader transform the content from FXL to reflowable in a fairly painless fashion 14:06:48 .... we have two proposals 14:06:56 ... they both have the same goals 14:06:57 present+ hadrien 14:07:04 ... but two different ways of achieving the goal 14:07:19 George has joined #epub 14:07:20 victoria has joined #epub 14:07:20 ... I'll do the first one, from Ken @ Circular Flo 14:07:33 present+ mgarrish 14:07:40 ... the idea of the content creator provide HTML files for each page 14:07:47 present+ 14:07:53 ... and then provide alternate stylesheets via media queries 14:07:55 George has joined #epub 14:08:09 ... this HTML doc has an FXL stylesheet and a reflow stylesheet 14:08:22 ... could we then have a flag that tells the RS that this book has an affordance 14:08:31 present+ 14:08:35 ... and then the RS would allow the user to flip back and forth between the stylesheets 14:08:40 ... they can pick FXL or reflow 14:08:46 https://paper.dropbox.com/doc/Visual-to-Textual-Explainer-K3nAwKn2vlVqRpFyZ9KHN 14:08:56 ... there are big questions 14:08:59 ... how would images work 14:09:06 ... enhanced content like audio/video 14:09:15 ... what are we missing with this idea? 14:09:17 q? 14:09:24 ... that's the first proposal 14:09:28 chair: wendyreid, dauwhe 14:09:41 hadrien: the other idea is... complementary 14:09:54 ... is that for a given FXL resource we would have an equivalent reflowable resource 14:10:03 q+ to ask how this differs from old iterations of MR and similar 14:10:08 ... we would use the fallback capabilities that already exist in EPUB 14:10:21 ... we would indicate that the fallback is also XHTML, but reflowable 14:10:28 ... the idea with that approach 14:10:37 ... even for titles that are extremely visual, like comics 14:10:40 George has joined #epub 14:10:52 ... you would still be able to have a reflowable alternative, describing what is going on 14:10:52 present+ laurence 14:11:03 ... it could cover text but also describe each panel 14:11:15 ... with that concept we wouldn't need anything new to the spec 14:11:21 George has joined #epub 14:11:24 ... it's an extension of what fallbacks are for 14:11:27 q+ 14:11:34 q+ 14:11:36 scribe+ 14:11:37 Bill_Kasdorf has joined #epub 14:11:39 ... and it avoids problems with multiple rendition and mapping doc 14:11:43 ... a single OPF 14:11:50 ... that's the core of it 14:11:57 ... I have a gist with an example 14:11:59 George has joined #epub 14:12:13 ack tzviya 14:12:13 tzviya, you wanted to ask how this differs from old iterations of MR and similar 14:12:17 Hadrien has joined #epub 14:12:26 -> Hadrien's approach https://gist.github.com/HadrienGardeur/7b2ed53b69379bd972250cc40e965f0d 14:12:27 tzviya: Hadrien mostly answered this, how it differs from multiple renditions 14:12:34 ... B&N had a magazine view 14:12:43 scribe+ 14:12:48 ... a fixed layout view, then a reflowable layer 14:13:01 Hadrien: I was involved with that 14:13:23 ... it was a multiple rendition EPUB, with a FXL rendition, a reflowable rendition, and an XML Mapping between the two 14:13:28 guests+ plh 14:13:30 ... so you could tap on FXL and go to reflow 14:13:40 George has joined #epub 14:13:44 ... one FXL doc could point to multiople reflowable docs 14:13:53 ... this is quite beyond what I was describing 14:13:58 ... this would have to be simple 14:14:08 ... a one:one mapping is easier 14:14:19 ... and make it easier to sniff the content 14:14:27 ... would we also need some metadata in OPF for this? 14:14:36 q+ 14:14:38 ... or would this be inferred? 14:14:49 ... things like this do exist, or at least have existed? 14:14:59 ... it was mostly for magazines where layout is important 14:15:02 s/?// 14:15:07 ack dauwhe 14:15:27 q+ 14:15:27 dauwhe: One concern - I have not seen evidence that fallbacks are supported aywhere 14:15:34 q+ 14:15:38 ack duga 14:16:04 q+ 14:16:05 duga: the more we make publishers do to make this work, the less likely it is to get one 14:16:06 Authoring of such multiple rendition documents is not easy. Unless authoring of such documents becomes much easier, I do not think that multiple-rendition documents will be widely used. 14:16:24 ... if we make publishers create an entirely new html doc, it's less likely to get done 14:16:34 ... we need to be concerned with combining resources 14:16:40 George has joined #epub 14:16:53 ... what happens when content flows from 1 xhtml file to another (like a multi-page list in a cookbook) 14:17:02 wendyreid: we are aware of the combining resource problems 14:17:03 ack CharlesL 14:17:30 CharlesL: re: metadata... yes we would put things in a11y metadata, including in summary 14:17:48 ... we started a CG yesterday to start working on new updates to a11y features 14:17:53 q+ 14:17:59 ack laurent_ 14:17:59 Which CG? 14:18:18 laurent_: fallbacks are not supported because there was no use case before 14:18:29 ... if there are a use, then it seems easy to implement in our reading system 14:18:40 George has joined #epub 14:18:43 present+ JenG 14:19:07 ack Hadrien 14:19:08 ... re: asking less of publishers... when FXL comes from InDesign, it's so hard to make it accessible, it might be easier to make a new accessible page 14:19:22 Hadrien: re: authoring complexity--that happens in both cases 14:19:32 q+ 14:19:33 ... defining a new stylesheet is complex 14:19:37 Here is the new Community Group link https://www.w3.org/community/a11y-discov-vocab/ and link to the draft https://w3c.github.io/a11y-discov-vocab/ 14:19:39 ... might be easier to make a new version 14:20:05 ... from an RS perspective, it would be easier to have an alternate resource than alternate stylesheets 14:20:11 +1 to Hadrien. Exporting from InDesign is still very messy. 14:20:14 ... there's no easy access through webviews 14:20:32 q? 14:20:33 ... I don't think we get anything for free. There will be work for content authors 14:20:40 George has joined #epub 14:20:46 ... just like an accessible reflow file is more work 14:20:55 ack mgarrish 14:21:14 mgarrish: content getting split is gonna be difficult 14:21:20 George has joined #epub 14:21:33 ... are we solving a problem for publishers or introducing a new problem? 14:21:45 ack avneeshsingh 14:21:49 ... I would be wary of a solution that only addresses one pain point and causes other pain points 14:22:08 avneeshsingh: many of things we have discussed are true 14:22:12 ... low vision is a blocker 14:22:20 ... so I haven't spent a lot of time on this 14:22:33 q+ 14:22:40 George has joined #epub 14:22:40 ... it could be a good idea to have an alternate page, but it goes against WCAG guidance on alternate content 14:23:01 ... there are negatives on both sides 14:23:09 q+ 14:23:19 ... fallbacks and other procedures: I don't think we need something as complex as fallbacks 14:23:46 ... we can just recommend that people put a link on top of an FXL page--just link to the reflowable version 14:24:01 ... let's see how publishers and users respond. We don't need to spec anything. 14:24:07 ... WE'll need new metadata 14:24:19 ack duga 14:24:40 George has joined #epub 14:24:41 duga: re: hadrien... I was not trying to say that the alternate resource approach was less complex, I think both will be hard. 14:24:53 present+ MasakazuKitahara 14:24:56 q+ 14:24:59 ... I'm concerned about both of the approaches. The publisher did have a reason to make the book FXL 14:25:08 present+ 14:25:10 ... this is going to be a difficult bridge to cross 14:25:10 ack Hadrien 14:25:17 Hadrien: to reply to what Avneesh suggested 14:25:34 ... it's easier if we want to test to implement fallbacks, than having interaction in a page 14:25:46 ... it's hard to support interactive content 14:26:02 ... we're not asking to spec things out in either approach 14:26:15 ... we should be able to experiment without adding things to the spec 14:26:31 ... I'm not a believer in JS interacting with the DOM 14:26:40 ... it will be more difficult 14:26:40 George has joined #epub 14:26:49 ... we're talking here about FXL as if it's one big thing 14:26:55 ... it depends on the type of content 14:27:08 ... magazine vs cookbooks, kids books, comics... 14:27:16 ... the largest adoption is comics/manga 14:27:18 George has joined #epub 14:27:24 ... we have the least options here 14:27:32 ... without going full alternate resource 14:27:39 ... we've talked aobut image maps 14:27:50 ... this is the most common content, and it's the hardest to make accessible 14:27:58 George has joined #epub 14:28:00 ... we should think about this 14:28:11 q? 14:28:24 ack we 14:28:36 wendyreid: avneesh, thanks for your comments 14:28:37 q+ 14:28:41 Creating radio drama or novelization of manga might be more practical. 14:28:45 ... we've had these discussions in the task force 14:28:53 ... we recognize this is fraught 14:29:00 ... we think this is testable 14:29:05 ... since we're not inventing new things 14:29:30 ack BenSchroeter 14:29:49 BenSchroeter: for comics the important thing is the story that the imagery is telling 14:30:10 ... no matter what technical solution you have to make text accessible, you need to address the images to make it understandable 14:30:39 George has joined #epub 14:30:41 ... there was a session at AHG where a universtiy team described a graphic novel, including describing the artwork, in terms of artisticness 14:30:47 ... they had a formula for doing that 14:31:14 q+ 14:31:17 q+ 14:31:19 George has joined #epub 14:31:22 q+ 14:31:25 ack ivan 14:31:25 ... that might be useful guidance to provide, what sort of framework do you use when you talk about the images in an image-rich comic. 14:31:44 George has joined #epub 14:31:45 ivan: side issue... whatever wwe do here 14:31:58 ... which leads to an addition to the spec, is non-normative 14:32:10 wendyreid: it depends on what solution we choose 14:32:17 ... there might be new metadata value 14:32:24 ivan: that doesn't bother me 14:32:38 ... if we get to normative statements affecting the reading systems, I could see them getting nervous 14:32:45 ack CharlesL 14:32:47 q+ George 14:32:53 CharlesL: not sure if this will solve all problems 14:33:02 ... using CSS flexbox can help 14:33:13 ... dynamically move things around depending on screen size 14:33:24 q+ 14:33:25 ... having panels set up in a flex grid might work 14:33:33 ack shiestyle 14:33:36 shiestyle: for manga content 14:33:40 George has joined #epub 14:33:45 ... not easy to explain only by one page 14:33:56 ... maybe manga has sometime one big picture with two pages 14:34:00 ... i have simple question 14:34:09 ... we need descrip;tion for each page 14:34:18 ... maybe simple or not so 14:34:26 ... less cost way for publisher to add accessiblity 14:34:32 ack mgarrish 14:34:36 q+ 14:34:38 mgarrish: ivan beat me to the quesiton 14:34:39 George has joined #epub 14:34:59 ... is this part about developing alt tech for switching... this seems like a CG thing 14:35:09 ... we're not quite sure what the solution it is 14:35:21 ... I wonder if we should separate the formal guidance from the new approaches 14:35:27 +1 to mgarrish 14:35:28 wendyreid: good idea 14:35:32 ack George 14:35:39 +1 it is ideal topic for CG, testing and improving and evaluating 14:35:39 George: I liek what ben had to say 14:36:00 s/liek/like/ 14:36:04 ... I think if we suggested that a ... instgead of a page by page description, a single text document that conveys the information 14:36:14 ... would be something that is pretty doable 14:36:23 s/instgead/instead/ 14:36:26 ... I could envision a publisher asking a vendor to give me a description of this 14:36:36 Like a transcript of the comic like we would do for videos etc. 14:36:39 George has joined #epub 14:36:51 ... when I've been contacted by legal, I've said it's difficult to make accessible 14:36:57 ... if there are easy solutions... 14:37:02 ... we should not do nothing 14:37:11 ... we need some guidance on an easy solution 14:37:16 George has joined #epub 14:37:33 ... we need to allow people with disabilities to be part of the community that are reading these things 14:37:39 ack Hadrien 14:37:49 Hadrien: I want to reply to charles and shiestyle 14:37:55 ... a big problem is granularity of the content 14:37:56 George has joined #epub 14:37:57 present+ Victor_Lopes 14:38:06 ... what charles is describing is not accessible but responsive 14:38:19 ... the content could be reorganized 14:38:23 ... it's not the same thing 14:38:35 ... and it would require content producer to break down their content like that 14:38:50 ... re: shiestyle's concern about spreads 14:39:00 ... you're never sure they will be displayed 14:39:06 ... you can't force them to use spreads 14:39:21 ... the RS might not display in spreads 14:39:44 ... and there's little capability of providing that info... we can't provide a fallback to two resources 14:40:00 q+ 14:40:06 ... it's hard for us to move up and down in granularity 14:40:28 present+ 14:40:33 ... and things like AHL and mapping docs have not been successful in the past 14:40:40 George has joined #epub 14:40:46 wendyreid: I'll take an action item to move this area of the work to the CG 14:40:57 q- 14:40:59 present+ 14:41:18 ... we talk all the time in the TF about being cognizant of the amount of work 14:41:29 ... things that are a lot of effort won't get adopted 14:41:40 ... but there is an appetite to do something to make docs more accessible 14:42:16 ... there is stuff that can be done in the editorial process for manga that publishers aren't doing 14:42:25 ... lots of comic creators write detailed scripts 14:42:39 George has joined #epub 14:42:41 ... Neil Gaiman's could have almost been alt text, it was so detailed 14:42:51 ... they need to think during the editorial process 14:43:06 ... look at your scripts! Talk to your authors! 14:43:20 ... the textual/visual proposal does have value in going to the CG 14:43:43 q? 14:43:45 ack we 14:43:46 ack wend 14:43:53 George: quick question 14:44:02 ...hearing about script presentation, writing of storyboards.. 14:44:16 ... if we were to recommend a textual descrption was provided 14:44:26 ... yes we would need metadata 14:44:40 George has joined #epub 14:44:42 ... how would a person get to this thing? Would it be a seapate link at the beginning of the book? 14:44:48 wendyreid: that's what we're trying to figure out now 14:44:55 ... might be separate docs 14:45:10 ... could be alt text 14:45:26 ... could be image maps 14:45:49 q+ 14:45:53 ... we also talked about panel-by-panel navigation from way back 14:45:59 George: you got little kids using this 14:46:12 q+ 14:46:25 ... the complexity of the UI... alt text doesn't present the flow and the story in an understandable way 14:46:25 ack duga 14:46:40 George has joined #epub 14:46:41 q+ laurence 14:46:47 duga: I don't know if we can spec an affordance on how to get into this mode 14:46:58 ... this might be for children, so you want a simple UI 14:47:13 George has joined #epub 14:47:19 ... just becasue I'm using talkback doesn't necessarily mean I need the description 14:47:26 ack Hadrien 14:47:37 Hadrien: it's not up to us to define the affordances 14:47:38 q+ 14:47:47 ... we can mention what we've discussed in the group 14:47:49 George has joined #epub 14:47:52 ... a single toggle as an affordance 14:47:58 ... and multiple ways this could work 14:48:01 ... side by side 14:48:15 ... toggle between two represenetations 14:48:25 George has joined #epub 14:48:25 ... could show the visual, then use TTS 14:48:46 ... it's tricky, you might want one affordance over the other 14:48:53 ... what's your preferred way of doing this? 14:49:07 ack laurence 14:49:40 George has joined #epub 14:49:43 laurence: did you consider blind people, low vision people, which might need a different layout 14:49:50 ... I think they are exclusive 14:49:59 ... either AT or enlarged layout 14:50:09 ... mixing the two might not be useful 14:50:17 ack CharlesL 14:50:19 CharlesL: agree there 14:50:24 ... different use cases 14:50:44 ... the other use case is cognative disabilities, who might need to know where to look next 14:50:56 q? 14:51:01 s/cognative/cognitive/ 14:51:19 wendyreid: this has been a productive discussion, we have work to do 14:51:23 +1 regarding cognitive 14:51:37 ... we should take a quick break before we talk about the next topics 14:51:40 George has joined #epub 14:51:42 reconvene at top of hour 14:51:55 14:52:17 George has joined #epub 15:02:25 zakim, next item 15:02:25 agendum 2 -- The Mystery of the URIs -- taken up [from wendyreid] 15:02:45 https://github.com/w3c/epub-specs/issues/1686 15:03:40 George has joined #epub 15:03:41 scribe+ JenG 15:06:37 present+ 15:07:40 George has joined #epub 15:07:55 dauwhe: Question - how should a reading system handle this situation? 15:08:18 George has joined #epub 15:08:26 q+ 15:09:01 ack ha 15:09:08 romain: I think that we need to hear from Reading Systems 15:09:27 scribe+ tzviya 15:09:39 George has joined #epub 15:10:48 q? 15:10:52 I apologize, apparently this does not work with a screen reader unless at some point I try another client. 15:11:40 George has joined #epub 15:12:01 q? 15:12:04 scribe+ 15:12:38 s/I apologize, apparently this does not work with a screen reader unless at some point I try another client./ 15:13:09 dauwhe: we have a proposal if ther's duplicate items to just ignore, but the first one 15:13:23 ... does it work for other RSs? 15:13:40 George has joined #epub 15:13:43 duga: I think we don't have EPUBs like that 15:13:52 ... because they don't pass EPUBcheck 15:13:53 For reading systems, duplicated resources are not really an issue when moving forward/backward in the spine. It becomes an issue when you need to "jump" to a resource (link or ToC), since we don't know where to jump to. 15:13:56 q+ 15:14:01 ack ro 15:14:16 romain: yes, now it is picked by EPUBcheck 15:14:25 The idea of getting rid of the second reference in the spine should work for reading systems. 15:14:26 q+ to confirm VitalSource also rejects via epubcheck 15:14:37 ack ri 15:14:37 rickj, you wanted to confirm VitalSource also rejects via epubcheck 15:14:39 ... but it's one of the reason for which we have RSs specifications 15:14:53 rickj: we also filters EPUBs via EPUBcheck 15:15:14 q+ 15:15:18 ack dug 15:15:22 q+ 15:15:26 ... it could be an issue for side loading EPUBs 15:15:35 q+ 15:15:40 George has joined #epub 15:15:47 duga: it may be an issue for linking 15:15:57 ... where the link will go? 15:15:58 ack dl 15:16:17 ... how many times the document will be displayed? 15:16:39 q+ 15:17:05 q+ 15:17:15 Dan: since we don't have a definition in the spec, but we are blocking it via EPUBcheck... I think it is not really important 15:17:25 ... to specify 15:17:27 ack mg 15:17:28 q+ 15:17:40 George has joined #epub 15:17:53 s/Dan/dlazin/ 15:18:33 mgarrish: I think there should be a consistent manage of non conformant EPUBs 15:18:37 ack dau 15:18:52 ack rom 15:19:02 dauwhe: my question is: is there any interoperable problem to solve? 15:19:04 q+ 15:19:28 q+ laurence 15:19:36 Hadrien: I think we don't know enough how RSs handle this problem 15:19:40 George has joined #epub 15:19:56 ... maybe for the moment a note in the spec if enough for RSs implementers 15:20:26 ... we may add it in the next EPUB version 15:20:32 ack iv 15:20:56 q+ ivan 15:20:57 ack lau 15:21:09 laurence: I think it's an authoring problem 15:21:40 George has joined #epub 15:21:43 ack iv 15:21:49 q+ 15:22:04 ... having multiple times the same document in the spine creates problems for pagelist 15:22:33 ivan: as an editor I think the core spec document have to say that the elements must not be repeated 15:22:53 ack mg 15:22:57 ... the RSs spec should say to ignore any multiple duplication of elements in the spine 15:23:36 ack du 15:23:40 George has joined #epub 15:23:42 mgarrish: It's difficult to answer... I think that adding a guideline in the RSs spec should be good 15:24:01 q+ laurence 15:24:26 q+ 15:24:35 duga: as a RS point of view I have multiple questions: links, display, annotations, bookmarks, etc. 15:24:54 ... what happen it the same document is twice (or more) in the spine? 15:25:00 ack lau 15:25:05 ... I think we need a guide on manage it 15:25:26 laurence: I think this case may happen in text-books 15:25:26 ack iv 15:25:40 George has joined #epub 15:26:01 q+ 15:26:23 q+ 15:26:24 ivan: maybe the solution may be not to remove the duplicate content 15:26:44 q+ 15:27:13 dauwhe: I think we should not remove content 15:27:26 ack dau 15:27:29 ack mg 15:27:40 George has joined #epub 15:27:59 mgarrish: I don't link the idea to hide the content, but I don't want to allow them on the authors side 15:28:15 q+ 15:28:21 ack ri 15:28:26 ... we can make a note explaining how RSs should manage these cases 15:28:40 George has joined #epub 15:28:52 ack du 15:28:57 I officially withdraw my proposal :-) 15:29:01 rickj: ??? (sorry, didn't get) 15:29:13 q? 15:29:40 George has joined #epub 15:29:56 duga: I may write something as a proposal for the note 15:30:48 https://github.com/w3c/epub-specs/issues/1681 15:30:57 dauwhe: ok, we ask brady to propose a text and then we can have a resolution in an another meeting 15:31:04 subtopic: https://github.com/w3c/epub-specs/issues/1681 15:31:11 q+ 15:31:12 my comment: I agree with comments from Brady and Matt, that showing it benefits the user (they see what the author wanted), the only issue is clicking on a link will take them to an unexpected place in the reading order (which is the bug/issue we can point to) 15:31:15 ack ro 15:31:40 George has joined #epub 15:31:44 romain: the issue is on how we resolve relative URLs in EPUB 15:32:28 ... this creates a lot of questions, since the URL parser algorith take two arguments as input 15:32:50 ... the relative URL and the root URL 15:33:09 ... so we started to question about which is the root URL for EPUBs 15:33:37 ... the spec already as a paragraph on URLs in EPUBs (in the OCF section) 15:33:40 George has joined #epub 15:34:23 ... we required for those URLs to be resolved as root relative URLs 15:34:47 ... so I don't understand why for OCF is ok to define it, but for EPUB contents is not 15:34:57 q? 15:35:01 q+ 15:35:04 ack iv 15:35:14 ... I think we should concentrate on how to resolve URLs in a general way 15:35:40 George has joined #epub 15:35:40 https://github.com/w3c/epubcheck/issues/1252 15:35:46 ivan: are you suggesting to use OCF section on URLs for the other documents? 15:36:06 romain: not really, I think there are other issues on URLs 15:36:14 George has joined #epub 15:36:42 q? 15:36:51 ... because the OCF section is underspecified 15:37:14 https://github.com/w3c/epub-specs/issues/1374 15:37:40 George has joined #epub 15:37:44 subtopic: https://github.com/w3c/epub-specs/issues/1374 15:38:03 https://github.com/w3c/epub-specs/issues/1374#issuecomment-847978623 15:38:38 q? 15:39:29 romain: I may summarize 15:39:40 George has joined #epub 15:39:46 ... the big problem is defining how to resolve relative URLs in an EPUB 15:40:00 ... most of the URLs we use are relative URLs 15:40:27 ... but an URL object is something which is parsed from an URL string 15:40:37 ... to make it absolute 15:40:51 ... it is done by the parsing algorith 15:41:18 ... I make an example 15:41:40 George has joined #epub 15:41:58 parse("doc.xhtml", "https://example.org") == "https://example.org/doc.xhtml" 15:42:31 ... for using this algorith we have to now the base URL (https://example.org) 15:43:23 ... the problem is that our spec doesn't define what is the URL of the EPUB (because it may be used in different locations: online, offline, ecc.) 15:43:40 George has joined #epub 15:43:43 http://example.org/publisher/mobydick.epub#/EPUB/package.opf 15:43:43 ... I'm going to show other examples 15:44:40 - parse("doc.xhtml", "http://example.org/publisher/mobydick.epub#/EPUB/package.opf") == "http://example.org/publisher/doc.xhtml" 15:44:58 - parse("../../doc.xhtml", "http://example.org/publisher/mobydick.epub#/EPUB/package.opf") == "http://example.org/doc.xhtml" // ⚠️ OUTSIDE OF CONTAINER 15:44:58 ... in this case I'm going outside of the EPUB 15:45:20 - parse("/doc.html", "http://example.org/publisher/mobydick.epub#/EPUB/package.opf") == "http://example.org/doc.xhtml" // ⚠️ OUTSIDE OF CONTAINER 15:45:40 George has joined #epub 15:45:56 VictorL has joined #epub 15:46:16 q? 15:46:19 ... that's why I think we should define which is the base URL, also for security issues 15:46:47 ... the solution should be unambiguious 15:47:04 ... the resulting URL should not go outside the container 15:47:34 ... resolving two relative URLs in two different EPUBs they should not resolve in the same absolute URL 15:47:40 George has joined #epub 15:47:53 ... the URL of the EPUB should not share the same origin 15:48:05 ... these are the 4 objectives of the ideal solution 15:48:14 q+ 15:48:19 ack iv 15:49:23 ivan: I remember that one solution may be to consider an EPUB as a localhost (with a unique port) 15:49:41 George has joined #epub 15:49:52 ... so the localhost:port is what represents the root for the EPUB 15:50:22 George has joined #epub 15:50:29 ... but if the RS works in a streaming way, it may not work (because the EPUB is not decompressed) 15:50:46 q+ 15:50:50 ... and if it goes out of the EPUB, the user gets a 404 15:50:50 ack rom 15:51:36 parse("/", "epub:/") == "epub:/" 15:51:43 parse("../../doc.xhtml", "epub:/EPUB/package.opf") == "epub:/doc.xhtml" 15:51:52 romain: yes, there are different approches. One is to use domains, another is to use a custom protocol scheme 15:52:15 ... I don't know which one is better 15:52:18 q? 15:52:28 q+ 15:52:47 ... from a RS point of view 15:53:12 ivan: I think defining a URI schema for that is not a good idea 15:53:40 George has joined #epub 15:54:11 romain: I don't think we'll come with a solution that will be used by the end user 15:54:12 ack duga 15:55:36 duga: I think there are 4 cases: local URLs, online URLs, jar URLs 15:55:40 George has joined #epub 15:55:50 q+ 15:55:53 ... I think is the last URL the problem 15:56:05 ... isn't it? 15:56:25 romain: yes, but also referencing to resources outside the package 15:57:06 q+ 15:57:19 duga: do we need to tell people how to display URLs inside on EPUBs (using fragments)? 15:57:33 ... I would propose to remove it 15:57:39 ack ha 15:57:40 George has joined #epub 15:57:40 q+ 15:58:11 somewhat realted, a gist from @annevk about ZIP URLs (from 8 years ago): https://gist.github.com/annevk/6174119 15:58:25 Karen has joined #epub 15:58:40 George has joined #epub 15:58:44 s/realted/related/ 15:58:54 Hadrien: referencing everything outside the archive is problematic specially for the content document 15:59:36 ... I don't think we should get to a specific resolution here, because the RSs have different solutions 15:59:55 (can someone replace me for scribing? :)) 16:00:01 ack rom 16:00:18 romain: removing that paragraph about the URL of the package document won't work 16:00:28 ... we need to tell people how to build them 16:00:32 thanks dauwhe 16:00:37 q? 16:00:55 ... at a minimium, we should base everything on the assumption that there is a url for the root of the container 16:01:08 jeff has joined #epub 16:01:08 ... and we leave it for the reading system to define 16:01:12 ... I'm not sure that will work 16:01:24 ... and we are back to the discussion that the RS spec should say something 16:01:27 ack dl 16:01:37 dlazin: there is another issue 16:01:39 https://github.com/w3c/epub-specs/issues/1843 16:01:40 George has joined #epub 16:01:42 ... about URIs for EPUBs 16:02:13 ... how do specify epub in cors/iframe policy? 16:02:19 ... I don't know how this is managed today 16:02:34 q+ 16:02:36 ... you need some way to say, hi, I am aware of this ebpu can it can iframe my content 16:02:38 ack ro 16:02:47 romain: this might not answer entirely 16:03:07 ... RS spec says, for scripting, reading system must associate a unique origin to the script 16:03:15 gpellegrino has joined #epub 16:03:23 ... a similar mechanism could be used to answer that issue about CORS/CSP 16:03:33 dlazin: is it a predicable url? 16:03:40 George has joined #epub 16:03:51 romain: this scripting mechanism is only about an origin--could be an opaque origin, doesn't have to be a url 16:04:00 ... opaque orign serializes to null 16:04:06 q? 16:04:06 s/orign/origin/ 16:04:21 ivan: where do we go from here 16:04:36 dauwhe: do we ask for help? 16:04:43 ivan: we have tried and failed before 16:04:51 ... we have been discussing these things 16:04:59 ... if we come up with a concrete proposal 16:05:16 ... and then check whether that solution is acceptable to the TAG or whoever 16:05:23 bkardell_ has joined #epub 16:05:27 ... my knowledge is not good enough to write a proposal 16:05:40 George has joined #epub 16:05:45 romain: I was supposed to come up with a proposal 16:05:59 ... I can write a summary of issue with possible approaches "paths" to solutions 16:06:44 ... I don't know enough about URLs and security to know all the plusses and minuses 16:06:53 ivan: we can't go to CR with this stuff open 16:07:17 ... it's unfortunate that Tess is not around, we might ask the TAG 16:07:23 ... and the TAG takes time 16:07:25 q+ 16:07:32 ... we have time pressure 16:07:40 George has joined #epub 16:08:10 ack dauwhe 16:08:11 dauwhe: could we talk to ping? 16:08:13 q+ 16:08:28 ack ro 16:08:47 romain: could we liase with Anne at WhatWG? 16:09:13 q+ 16:09:22 ivan: I worry about that 16:09:40 George has joined #epub 16:10:05 tzviya: talking to Tess would be good 16:10:19 ivan: if we have a proposal that romain can put together 16:10:35 ... my first option would be to involve tess 16:10:47 romain: I can summarize the problem statement 16:11:04 q+ laurence 16:11:07 laurent_: tests will take time 16:11:25 ... why don't we just say that path-absolute URLs are illegal 16:11:26 q+ 16:11:40 George has joined #epub 16:11:44 ack laurent_ 16:11:45 ... and just update epubcheck 16:11:50 q+ 16:12:05 ... to post an error if there's a slash at the beginning of URL 16:12:15 path-absolute URLs are a red herring. the issue is with *any* relative URL really. 16:12:41 laurence: could we have a fifth objective, easy to move to web publication? 16:12:50 ack rom 16:13:22 romain: it's about any relative urls. Just dealing with path-relative won't solve the issue 16:13:25 ack lau 16:13:27 ack mg 16:13:40 George has joined #epub 16:13:49 mgarrish: we have 1725 PR, which forbids path-absolute URLs. Is there any reason we shouldn't merge that? 16:14:05 ... should we close that? Or integrate it because it deals with part of the question? 16:14:09 q? 16:14:13 q+ 16:14:20 ack ivan 16:14:20 wendyreid: have we exhausted this? 16:14:38 ivan: to answer matt, that one can go in 16:14:51 +1 16:14:55 ... using root-relative IRIs is a bad idea for something like epub, where the root url is unclear 16:15:01 q? 16:15:31 Proposed: Merge PR 1725 16:15:36 +1 16:15:36 +1 16:15:38 +1 16:15:39 +1 16:15:40 +1 16:15:40 George has joined #epub 16:15:40 +1 16:15:40 +1 16:15:40 +1 16:15:40 +1 16:15:41 +1 16:15:48 +1 16:15:48 +1 16:15:49 +1 16:15:49 +1 16:15:50 +1 16:15:51 +1 16:15:52 +1 16:15:56 +1 16:16:02 RESOLVED: Merge PR 1725 16:16:59 rrsagent, draft minutes 16:16:59 I have made the request to generate https://www.w3.org/2021/10/28-epub-minutes.html ivan 16:17:40 George has joined #epub 16:17:51 reconvene at half past! 16:18:20 George has joined #epub 16:21:40 George has joined #epub 16:26:45 For the records (to be put to the right place in the final minutes) brady put in a proposal for the duplicate items: https://github.com/w3c/epub-specs/issues/1686#issuecomment-954839703 16:27:40 George has joined #epub 16:31:29 scribe+ 16:31:54 zakim, next item 16:31:54 agendum 3 -- Testing Update and Discussion -- taken up [from wendyreid] 16:31:56 wendyreid: this last segment of the meeting is about testing 16:32:33 dlazin: one of the key requirements of CR is that we prove every normative statement is implementable - we do this by showing two implementations for each statement 16:32:49 https://w3c.github.io/epub-tests/ 16:32:50 ... we've built the test framework, and have started making the tests themselves 16:33:05 ... credit for this reporting framework to ivan 16:33:16 ... automatically compiled from all the tests that we check into the github repo 16:33:22 ... (about 57 in total now) 16:33:35 ... each test links to the statement under test in the spec 16:33:40 George has joined #epub 16:33:43 https://w3c.github.io/epub-specs/epub33/core/#sec-shared-attrs 16:33:51 ... currently links go to the github version of the spec (unpublished) 16:33:52 https://w3c.github.io/epub-specs/epub33/rs/#sec-pub-resources 16:34:09 Mickael has joined #epub 16:34:10 ... in most of these documents there are expandable drop down that link back to the tests 16:34:18 ... these are hidden in the published version of spec 16:34:28 ... so this works as a bi-directional link 16:34:48 ... we want to make sure every MUST or MUST NOT has tests (but also the SHOULDs and MAYs) 16:34:58 ... total number of tests should be about 300 16:35:25 ... wendyreid demoed the test writing process, and it only took about 5 minutes for one test 16:35:37 ... the bottom of the test document has the names of the contributors 16:35:40 George has joined #epub 16:35:52 ... what we are requesting now and help from the WG to fill out the test corpus 16:36:04 ... you can borrow from what is already there to make your own tests 16:36:08 https://w3c.github.io/epub-tests/contributing 16:36:25 ... this is a contribution guideline - step by step directions on how to make a test for us 16:36:25 https://w3c.github.io/epub-tests/results 16:36:44 dauwhe has joined #epub 16:36:44 ... ivan also made a report of the implementation results for us 16:36:54 ... so far this document is populated with fake data 16:37:14 q? 16:37:16 q+\ 16:37:22 q+ 16:37:24 ... if you are RS dev and are interested in starting the assessment part of the test, you can do so 16:37:27 ack \ 16:37:40 George has joined #epub 16:37:45 duga: if i decide to publish all these test documents, is that allowed? No IP restrictions? 16:37:59 dlazin: not that i know of, but i'm not legal expert 16:38:10 duga: i was going to put the epubs into the Play store 16:38:40 dlazin: my concern would be that some of the tests have images in them, and minor assets of that type 16:38:51 ... at the moment the tests are a bit in flux 16:39:02 ... things are being renamed, etc. 16:39:20 ack rickj 16:39:23 ... you may have to wait until we get to a more solid place before you put them in the store, so there's less cleanup later 16:39:40 q+ 16:39:43 rickj: on versioning, github would be the way we'd know if a test had changed, right? 16:40:01 q+ 16:40:02 dlazin: handling re-names in github is tedious, so its not always easy to tell what is update and what is new 16:40:22 ... i'm new here, and there are some weaknesses in the test 16:40:42 ... e.g. Apple Books doesn't display nav if nav contains only a single link, so we had to go back and fix a bunch of tests 16:40:51 ack iva 16:40:51 ... but you'd only be re-testing if you failed 16:41:05 rickj: well, and we'd re-test for any test that changed, too 16:41:25 ... is there a document on how to do the test as a RS vendor? 16:41:52 dlazin: the bottom two sections of that how-to link that i posted earlier contains the information you'd need 16:42:25 ivan: we have to realize that we have about a year for RS to do testing 16:42:34 ... the rush is more in populating the test bank 16:42:52 q+ 16:42:55 ... to get to official CR phase is that we must show a clear path on how we plan to do testing 16:43:33 ... the reason why we planned a long CR phase in our charter is that the way that different RS run the tests will be unique to the RS 16:43:39 ack wendyreid 16:44:07 wendyreid: when I run the tests I'll probably uploading them to the Kobo server too 16:44:14 q+ 16:44:17 ... i can quarantine the test books so they're not public 16:44:49 ... once we establish an initial test pack, we might want to delineate a version of the test suite and group it together as a collection 16:45:13 ... and then if there are changes, it'll be easier to track that change with versioning 16:45:39 ... if there are updates to files, its not hard for me as RS vendor to update the test in my system 16:45:51 ... i just want to know which tests are done, and which ones i need to re-test 16:45:59 rickj has joined #epub 16:46:06 q+ 16:46:09 ack dlazin 16:46:19 ... so we might give a pointer to the test collection, but a pointer to tests which have been recently updated 16:46:40 dlazin: we've seen a lot of value in proving the process here, has been very valuable 16:47:30 ... if there are RS vendors who have an appetite for getting started, it would be helpful to hear your feedback 16:47:44 ... when we started we had a tracking spreadsheet - we've since dropped this 16:48:16 ... what you want to do to see where tests have already been created are scanning the github version of spec for the test dropdown 16:48:25 ... the areas where we are most looking for help is FXL and MO 16:48:48 ... testing the RS spec is fun and easy, but testing core spec has yet to be tackled 16:49:22 ack ivan 16:49:25 ... lots of cases where the author has to do certain things, and we are still discussing in testing TF how to handle this 16:49:40 ... please join us in our meetings, and maybe we should start a testing Slack 16:49:57 slack channel?? we have w3c slack channels? Pointers, please! 16:50:14 ivan: wendyreid i think what you were referring to is like a github release 16:50:45 ... for some of the RS testing means that they have to put test epubs into a public space 16:50:58 ... maybe its worth adding a copyright statement into the metadata of each test 16:51:06 ... probably the w3c copyright into each of those tests 16:51:13 ... maybe this can be automated 16:51:24 q? 16:51:25 ... we wouldn't use it for the reporting mechanism though 16:51:54 ... dlazin also referred that its not always obvious what testing means for some assertions in content 16:52:10 ... similarly we have issues with vocabs in the spec 16:52:28 ... its the kind of testing we have to do in terms of showing that metadata is used in practice 16:52:52 romain_ has joined #epub 16:52:58 ... collecting data to show that our normative metadata values are actually used by authoring community 16:53:08 ... similarly, what does CR phase mean for a11y spec? 16:53:24 ... not sure how a11y WGs normally do this. Maybe talk to Michael Cooper? 16:53:36 ack rickj 16:53:38 ... but we must have an answer to this before CR 16:53:59 rickj: there are a lot of very good, still used, tests that Markus wrote back in the day 16:54:02 ... can that be part of this? 16:54:15 ivan: we could roll them in, but not sure how we would use and evaluate those tests 16:54:32 q+ 16:54:39 ... the mechanism we have today may or may not be appropriate, currently unclear 16:55:11 ... we may have to handle reporting of these a11y test results may be separate 16:55:28 rickj: as a RS vendor I'd love to have a single comprehensive suite of tests 16:55:29 ack tzviya 16:55:40 ivan: rickj can you share point to the tests you were talking about? 16:55:54 q+ 16:56:06 tzviya: i think Marisa handles those tests. And I think those tests are different, because you're also testing interaction between epub, RS, and AT. 16:56:22 rickj: sure, as long as we can get all the tests into a single suite 16:56:36 ack avneeshsingh 16:56:41 tzviya: and let's not forget about the a11y metadata user guide 16:57:04 old epubtest: https://github.com/IDPF/epub-testsuite/tree/main/content/30 16:57:08 avneeshsingh: i think you're talking about the old epubtest.org where there were sample content. Now epubtest.org is more testing experience. 16:57:18 yes! Those unit tests 16:57:29 ... the older tests may help, as those as more aligned with you current testing process 16:57:41 ... those were structured as unit tests 16:57:49 ... we still have those in archive somewhere 16:58:04 ... ivan were you also thinking about how we would prove implementation? 16:58:20 ivan: question is what implementation means in terms of a11y spec? 16:58:41 q+ 16:59:01 avneeshsingh: members here are using it already 16:59:22 ivan: so we'd just have to prove that somehow, that the community has accepted it 16:59:37 ... i think mgarrish did some work collecting data about the usage of certain features 16:59:40 q+ 17:00:05 zakim, close the queue 17:00:05 ok, wendyreid, the speaker queue is closed 17:00:27 avneeshsingh: when i say that publishers are using epub a11y spec i mean they are using epub a11y 1.0 - their migration to 1.1 will be upcoming 17:00:43 metadata cg: https://github.com/w3c/a11y-discov-vocab 17:00:51 ack mgarrish 17:00:58 q+ laurence 17:01:04 ... there is also a group looking into a11y governance that could help 17:01:20 mgarrish: there is a part of the a11y spec that just refers to WCAG 17:01:28 ... and there is the metadata component 17:01:40 q- 17:01:53 ... showing implementation of the metadata component should be doable 17:02:39 laurence: if there are no errors in the first tab of an ACE report then most of the a11y requirements are being respected 17:02:40 q+ to comment on Ace and SMART 17:02:47 q+ 17:02:50 ... there is also another tab in ACE about what metadata is being used 17:02:56 ... so is that enough of a test, maybe? 17:03:00 all GCA publishers are already putting in this a11y metadata and VitalSource is showing it already from multiple publishers so I think this is already done. 17:03:02 zakim, open the queue 17:03:02 ok, wendyreid, the speaker queue is open 17:03:09 q+ avn 17:03:15 q+ mgarrish 17:03:20 q- 17:03:24 zakim, close the queue 17:03:24 ok, wendyreid, the speaker queue is closed 17:03:43 Brady and I have to run, but we are excited to see so much interest! Please join us at the next testing meeting, which you will see on the EPUB calendar 17:03:59 george: in terms of the implementation we have display of metadata from VST, NELS, etc. We have many vendors certified for producing a11y content. And many publishers in higher ed. are doing this right now. 17:04:07 ... I don't think we'll have any issue showing implementation of this 17:04:26 avneeshsingh: next year we're working on additional a11y checking tools 17:05:15 wendyreid: thank you all for attending and your contributions. We do not have a regularly scheduled meeting next week. We will resume regular meetings 2nd week of Nov. 17:05:23 ... thank you to all scribes 17:05:34 ... cheers for the wonderful discussion! 17:05:38 rrsagent, draft minutes 17:05:38 I have made the request to generate https://www.w3.org/2021/10/28-epub-minutes.html ivan 17:05:51 CharlesL has left #epub 17:05:57 dkaplan3 has left #epub 17:09:42 rrsagent, bye 17:09:42 I see no action items