EPUB 3 WG TPAC Face to Face Meeting Day 2 — Minutes

Date: 2021-10-29

See also the Agenda and the IRC Log

Attendees

Present: Rick Johnson, Dave Cramer, Ivan Herman, Deborah Kaplan, Avneesh Singh, Wendy Reid, Toshiaki Koike, Masakazu Kitahara, Shinya Takami (高見真也), Matthew Chan, Ben Schroeter, Matt Garrish, Yu-Wei Chang (Yanni), Charles LaPierre, Brady Duga, Aimee Ubbink, Tzviya Siegman, John Roque, Jen Goulden, Gregorio Pellegrino, George Kerscher, Romain Deltour, Murata Makoto, Victoria Lee, Laurent Le Meur, Theresa O’Connor, Dan Lazin, Hadrien Gardeur, Laurence Zaysser, Victor Lopes, Bill Kasdorf

Regrets:

Guests: John Kirkwood, Louis Maher, Philippe le Hégaret, Elizabeth Dunn, Rachel Yager, Myles Maxfield, Breixo Pastoriza, michaël, Peter Bruhn Andersen, Shadi Abou-Zahra, Jeff Jaffe

Chair: Wendy Reid, Dave Cramer

Scribe(s): Dave Cramer, Wendy Reid, Brady Duga, Jen Goulden, Tzviya Siegman, Gregorio Pellegrino, Matthew Chan

Content:

• 1. FXL Accessibility.
• 2. The Mystery of the URIs.
  • 2.1. Define what RS should do when the manifest has duplicate entries (issue epub-specs#1686)
  • 2.2. Are root-relative paths valid? (issue epub-specs#1681)
  • 2.3. “IRI of the Package Document”: what is this exactly? (issue epub-specs#1374)
• 3. Testing Update and Discussion.
• 4. Resolutions

Wendy Reid: good day, everyone.

Wendy Reid: good meeting last night.

1. FXL Accessibility.

Dave Cramer: .., let’s talk about the FXL a11y task force.

Wendy Reid: putting together a guidance doc for publishers about how to build better FXL books.
… this is best practices, things we’ve learned over the years..
… they won’t be perfect but they can be better.
… the doc is incomplete and a work in progress.
… we talk about reading order, alt text, navigation.
… there will be a section on legibility.
… a11y metadata, tables….
… we want to build some examples.
… with real content.
… showing it’s possible to make accessible complex fixed layout content.
… the other thing is that we’ve been working with.
… we still can’t make FXL completely accessible.
… a big problem is low-vision users.
… if you can’t increase the font size effectively, that use case just doesn’t work..
… this is where we’re looking for ideas. It’s experimental..
… we have two proposals..
… we’ve struggled to name it.
… visual/textual affordance.
… can we develop a way in EPUB.
… for a content creator let the reader transform the content from FXL to reflowable in a fairly painless fashion.
… . we have two proposals.
… they both have the same goals.
… but two different ways of achieving the goal.
… I’ll do the first one, from Ken @ Circular Software.
… The idea of the content creator provide HTML files for each page.
… and then provide alternate stylesheets via media queries.
… this HTML doc has an FXL stylesheet and a reflow stylesheet.
… could we then have a flag that tells the RS that this book has an affordance.
… and then the RS would allow the user to flip back and forth between the stylesheets.
… they can pick FXL or reflow.

Wendy Reid: See Ken’s proposal.

Wendy Reid: there are big questions.
… how would images work.
… enhanced content like audio/video.
… what are we missing with this idea?.
… that’s the first proposal.

Hadrien Gardeur: the other idea is… complementary.
… is that for a given FXL resource we would have an equivalent reflowable resource.
… we would use the fallback capabilities that already exist in EPUB.
… we would indicate that the fallback is also XHTML, but reflowable.
… the idea with that approach.
… even for titles that are extremely visual, like comics.
… you would still be able to have a reflowable alternative, describing what is going on.
… it could cover text but also describe each panel.
… with that concept we wouldn’t need anything new to the spec.
… it’s an extension of what fallbacks are for.
… and it avoids problems with multiple rendition and mapping doc.
… a single OPF.
… that’s the core of it.
… I have a gist with an example.

Tzviya Siegman: Hadrien mostly answered this, how it differs from multiple renditions.
… B&N had a magazine view.
… a fixed layout view, then a reflowable layer.

Hadrien Gardeur: I was involved with that.
… it was a multiple rendition EPUB, with a FXL rendition, a reflowable rendition, and an XML Mapping between the two.
… so you could tap on FXL and go to reflow.
… one FXL doc could point to multiple reflowable docs.
… this is quite beyond what I was describing.
… this would have to be simple.
… a one-to-one mapping is easier.
… and make it easier to sniff the content.
… would we also need some metadata in OPF for this?.
… or would this be inferred?.
… things like this do exist, or at least have existed.
… it was mostly for magazines where layout is important.

Dave Cramer: One concern - I have not seen evidence that fallbacks are supported anywhere.

Brady Duga: the more we make publishers do to make this work, the less likely it is to get one.

Murata Makoto: 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..

Brady Duga: if we make publishers create an entirely new html doc, it’s less likely to get done.
… we need to be concerned with combining resources.
… what happens when content flows from 1 xhtml file to another (like a multi-page list in a cookbook).

Wendy Reid: we are aware of the combining resource problems.

Charles LaPierre: re: metadata… yes we would put things in a11y metadata, including in summary.
… we started a CG yesterday to start working on new updates to a11y features.

Murata Makoto: Which CG?.

Charles LaPierre: 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/.

Laurent Le Meur: fallbacks are not supported because there was no use case before.
… if there are a use, then it seems easy to implement in our reading system.
… 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.

Hadrien Gardeur: re: authoring complexity–that happens in both cases.
… defining a new stylesheet is complex.
… might be easier to make a new version.
… from an RS perspective, it would be easier to have an alternate resource than alternate stylesheets.

Bill Kasdorf: +1 to Hadrien. Exporting from InDesign is still very messy..

Hadrien Gardeur: there’s no easy access through webviews.
… I don’t think we get anything for free. There will be work for content authors.
… just like an accessible reflow file is more work.

Matt Garrish: content getting split is gonna be difficult.
… are we solving a problem for publishers or introducing a new problem?.
… I would be wary of a solution that only addresses one pain point and causes other pain points.

Avneesh Singh: many of things we have discussed are true.
… low vision is a blocker.
… so I haven’t spent a lot of time on this.
… it could be a good idea to have an alternate page, but it goes against WCAG guidance on alternate content.
… there are negatives on both sides.
… fallbacks and other procedures: I don’t think we need something as complex as fallbacks.
… we can just recommend that people put a link on top of an FXL page–just link to the reflowable version.
… let’s see how publishers and users respond. We don’t need to spec anything..
… we’ll need new metadata.

Brady Duga: re: hadrien… I was not trying to say that the alternate resource approach was less complex, I think both will be hard..
… I’m concerned about both of the approaches. The publisher did have a reason to make the book FXL.
… this is going to be a difficult bridge to cross.

Hadrien Gardeur: to reply to what Avneesh suggested.
… it’s easier if we want to test to implement fallbacks, than having interaction in a page.
… it’s hard to support interactive content.
… we’re not asking to spec things out in either approach.
… we should be able to experiment without adding things to the spec.
… I’m not a believer in JS interacting with the DOM.
… it will be more difficult.
… we’re talking here about FXL as if it’s one big thing.
… it depends on the type of content.
… magazine vs cookbooks, kids books, comics….
… the largest adoption is comics/manga.
… we have the least options here.
… without going full alternate resource.
… we’ve talked about image maps.
… this is the most common content, and it’s the hardest to make accessible.
… we should think about this.

Murata Makoto: Creating radio drama or novelization of manga might be more practical..

Wendy Reid: avneesh, thanks for your comments.
… we’ve had these discussions in the task force.
… we recognize this is fraught.
… we think this is testable.
… since we’re not inventing new things.

Ben Schroeter: for comics the important thing is the story that the imagery is telling.
… no matter what technical solution you have to make text accessible, you need to address the images to make it understandable.
… there was a session at AHG where a university team described a graphic novel, including describing the artwork, in terms of “artisticness”.
… they had a formula for doing that.
… 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..

Ivan Herman: side issue… whatever we do here which leads to an addition to the spec, is non-normative.

Wendy Reid: it depends on what solution we choose.
… there might be new metadata value.

Ivan Herman: that doesn’t bother me.
… if we get to normative statements affecting the reading systems, I could see them getting nervous.

Charles LaPierre: not sure if this will solve all problems.
… using CSS flexbox can help.
… dynamically move things around depending on screen size.
… having panels set up in a flex grid might work.

Shinya Takami (高見真也): for manga content.
… not easy to explain only by one page.
… maybe manga has sometime one big picture with two pages.
… i have simple question.
… we need description for each page.
… maybe simple or not so.
… less cost way for publisher to add accessibility.

Matt Garrish: ivan beat me to the question.
… is this part about developing alt tech for switching… this seems like a CG thing.
… we’re not quite sure what the solution it is.
… I wonder if we should separate the formal guidance from the new approaches.

Ivan Herman: +1 to mgarrish.

Wendy Reid: good idea.

Avneesh Singh: +1 it is ideal topic for CG, testing and improving and evaluating.

George Kerscher: I like what Ben had to say.
… I think if we suggested that a … instead of a page by page description, a single text document that conveys the information.
… would be something that is pretty doable.
… I could envision a publisher asking a vendor to give me a description of this.

Charles LaPierre: Like a transcript of the comic like we would do for videos etc..

George Kerscher: when I’ve been contacted by legal, I’ve said it’s difficult to make accessible.
… if there are easy solutions….
… we should not do nothing.
… we need some guidance on an easy solution.
… we need to allow people with disabilities to be part of the community that are reading these things.

Hadrien Gardeur: I want to reply to charles and shiestyle.
… a big problem is granularity of the content.
… what charles is describing is not accessible but responsive.
… the content could be reorganized.
… it’s not the same thing.
… and it would require content producer to break down their content like that.
… re: shiestyle’s concern about spreads.
… you’re never sure they will be displayed.
… you can’t force them to use spreads.
… the RS might not display in spreads.
… and there’s little capability of providing that info… we can’t provide a fallback to two resources.
… it’s hard for us to move up and down in granularity.
… and things like AHL and mapping docs have not been successful in the past.

Wendy Reid: I’ll take an action item to move this area of the work to the CG.
… we talk all the time in the TF about being cognizant of the amount of work.
… things that are a lot of effort won’t get adopted.
… but there is an appetite to do something to make docs more accessible.
… there is stuff that can be done in the editorial process for manga that publishers aren’t doing.
… lots of comic creators write detailed scripts.
… Neil Gaiman’s could have almost been alt text, it was so detailed.
… they need to think during the editorial process.
… look at your scripts! Talk to your authors!.
… the textual/visual proposal does have value in going to the CG.

George Kerscher: quick question.
… hearing about script presentation, writing of storyboards…
… if we were to recommend a textual description was provided.
… yes we would need metadata.
… how would a person get to this thing? Would it be a separate link at the beginning of the book?.

Wendy Reid: that’s what we’re trying to figure out now.
… might be separate docs.
… could be alt text.
… could be image maps.
… we also talked about panel-by-panel navigation from way back.

George Kerscher: you got little kids using this.
… the complexity of the UI… alt text doesn’t present the flow and the story in an understandable way.

Brady Duga: I don’t know if we can spec an affordance on how to get into this mode.
… this might be for children, so you want a simple UI.
… just because I’m using talk-back doesn’t necessarily mean I need the description.

Hadrien Gardeur: it’s not up to us to define the affordances.
… we can mention what we’ve discussed in the group.
… a single toggle as an affordance.
… and multiple ways this could work.
… side by side.
… toggle between two representations.
… could show the visual, then use TTS.
… it’s tricky, you might want one affordance over the other.
… what’s your preferred way of doing this?.

Laurence Zaysser: did you consider blind people, low vision people, which might need a different layout.
… I think they are exclusive.
… either AT or enlarged layout.
… mixing the two might not be useful.

Charles LaPierre: agree there.
… different use cases.
… the other use case is cognitive disabilities, who might need to know where to look next.

John Kirkwood: +1 regarding cognitive.

Wendy Reid: this has been a productive discussion, we have work to do.
… we should take a quick break before we talk about the next topics.

2. The Mystery of the URIs.

2.1. Define what RS should do when the manifest has duplicate entries (issue epub-specs#1686)

See github issue epub-specs#1686.

Dave Cramer: Question - how should a reading system handle this situation?.

Romain Deltour: I think that we need to hear from Reading Systems.

Hadrien Gardeur: 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..
… The idea of getting rid of the second reference in the spine should work for reading systems..

Dave Cramer: we have a proposal if there’s duplicate items to just ignore, but the first one.
… does it work for other RSs?.

Brady Duga: I think we don’t have EPUBs like that.
… because they don’t pass EPUBcheck.

Romain Deltour: yes, now it is picked by EPUBcheck.
… but it’s one of the reason for which we have RSs specifications.

Rick Johnson: we also filters EPUBs via EPUBcheck.
… it could be an issue for side loading EPUBs.

Brady Duga: it may be an issue for linking.
… where the link will go?.
… how many times the document will be displayed?.

Dan Lazin: since we don’t have a definition in the spec, but we are blocking it via EPUBcheck… I think it is not really important.
… to specify.

Matt Garrish: I think there should be a consistent manage of non conformant EPUBs.

Dave Cramer: my question is: is there any interoperable problem to solve?.

Hadrien Gardeur: I think we don’t know enough how RSs handle this problem.
… maybe for the moment a note in the spec if enough for RSs implementers.
… we may add it in the next EPUB version.

Laurence Zaysser: I think it’s an authoring problem.
… having multiple times the same document in the spine creates problems for pagelist.

Ivan Herman: as an editor I think the core spec document have to say that the elements must not be repeated.
… the RSs spec should say SHOULD ignore any multiple duplication of elements in the spine.

Matt Garrish: It’s difficult to answer… I think that adding a guideline in the RSs spec should be good.

Brady Duga: as a RS point of view I have multiple questions: links, display, annotations, bookmarks, etc..
… what happen it the same document is twice (or more) in the spine?.
… I think we need a guide on manage it.

Laurence Zaysser: I think this case may happen in text-books.

Ivan Herman: maybe the solution is to remove the duplicate content.

Dave Cramer: I think we should not remove content.

Matt Garrish: I don’t link the idea to hide the content, but I don’t want to allow them on the authors side.
… we can make a note explaining how RSs should manage these cases.

Ivan Herman: I officially withdraw my proposal :-).

Rick Johnson: 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).

Brady Duga: I may write something as a proposal for the note.

Ivan Herman: For the records brady put in a proposal for the duplicate items before the end of the call: https://github.com/w3c/epub-specs/issues/1686#issuecomment-954839703.

Dave Cramer: ok, we ask brady to propose a text and then we can have a resolution in an another meeting.

2.2. Are root-relative paths valid? (issue epub-specs#1681)

See github issue epub-specs#1681.

Romain Deltour: the issue is on how we resolve relative URLs in EPUB.
… this creates a lot of questions, since the URL parser algorith take two arguments as input.
… the relative URL and the root URL.
… so we started to question about which is the root URL for EPUBs.
… the spec already as a paragraph on URLs in EPUBs (in the OCF section).
… we required for those URLs to be resolved as root relative URLs.
… so I don’t understand why for OCF is ok to define it, but for EPUB contents is not.
… I think we should concentrate on how to resolve URLs in a general way.

Dave Cramer: See see epubcheck issue.

Ivan Herman: are you suggesting to use OCF section on URLs for the other documents?.

Romain Deltour: not really, I think there are other issues on URLs.
… because the OCF section is underspecified.

2.3. “IRI of the Package Document”: what is this exactly? (issue epub-specs#1374)

See github issue epub-specs#1374.

Dave Cramer: See more detailed explanation.

Romain Deltour: I may summarize.
… the big problem is defining how to resolve relative URLs in an EPUB.
… most of the URLs we use are relative URLs.
… but an URL object is something which is parsed from an URL string.
… to make it absolute.
… it is done by the parsing algorith.
… I make an example.

parse("doc.xhtml", "https://example.org") == "https://example.org/doc.xhtml".

Romain Deltour: for using this algorith we have to now the base URL (https://example.org).
… 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.).

Romain Deltour: e.g., http://example.org/publisher/mobydick.epub#/EPUB/package.opf.

Romain Deltour: I’m going to show other examples.

parse("doc.xhtml", "http://example.org/publisher/mobydick.epub#/EPUB/package.opf") == "http://example.org/publisher/doc.xhtml".

parse("../../doc.xhtml", "http://example.org/publisher/mobydick.epub#/EPUB/package.opf") == "http://example.org/doc.xhtml" // ⚠️ OUTSIDE OF CONTAINER.

Romain Deltour: in this case I’m going outside of the EPUB.

parse("/doc.html", "http://example.org/publisher/mobydick.epub#/EPUB/package.opf") == "http://example.org/doc.xhtml" // ⚠️ OUTSIDE OF CONTAINER.

Romain Deltour: that’s why I think we should define which is the base URL, also for security issues.
… the solution should be unambiguious.
… the resulting URL should not go outside the container.
… resolving two relative URLs in two different EPUBs they should not resolve in the same absolute URL.
… the URL of the EPUB should not share the same origin.
… these are the 4 objectives of the ideal solution.

Ivan Herman: I remember that one solution may be to consider an EPUB as a localhost (with a unique port).
… so the localhost:port is what represents the root for the EPUB.
… but if the RS works in a streaming way, it may not work (because the EPUB is not decompressed).
… and if it goes out of the EPUB, the user gets a 404.

Romain Deltour: yes, there are different approches. One is to use domains, another is to use a custom protocol scheme:.

parse("/", "epub:/") == "epub:/".

parse("../../doc.xhtml", "epub:/EPUB/package.opf") == "epub:/doc.xhtml".

Romain Deltour: I don’t know which one is better.
… from a RS point of view.

Ivan Herman: I think defining a URI scheme for that is not a good idea.

Romain Deltour: I don’t think we’ll come with a solution that will be used by the end user.

Brady Duga: I think there are 4 cases: local URLs, online URLs, jar URLs.
… I think is the last URL the problem.
… isn’t it?

Romain Deltour: yes, but also referencing to resources outside the package.

Brady Duga: do we need to tell people how to display URLs inside on EPUBs (using fragments)?.
… I would propose to remove it.

Romain Deltour: somewhat related, a gist from @annevk about ZIP URLs (from 8 years ago): https://gist.github.com/annevk/6174119.

Hadrien Gardeur: referencing everything outside the archive is problematic specially for the content document.
… I don’t think we should get to a specific resolution here, because the RSs have different solutions.

Romain Deltour: removing that paragraph about the URL of the package document won’t work.
… we need to tell people how to build them.

Romain Deltour: at a minimium, we should base everything on the assumption that there is a url for the root of the container.
… and we leave it for the reading system to define.
… I’m not sure that will work.
… and we are back to the discussion that the RS spec should say something.

See github issue epub-specs#1843.

Dan Lazin: there is another issue: https://github.com/w3c/epub-specs/issues/1843.
… about URIs for EPUBs.
… how do specify epub in cors/iframe policy?.
… I don’t know how this is managed today.
… you need some way to say, hi, I am aware of this epub can it can iframe my content.

Romain Deltour: this might not answer entirely.
… RS spec says, for scripting, reading system must associate a unique origin to the script.
… a similar mechanism could be used to answer that issue about CORS/CSP.

Dan Lazin: is it a predicable url?.

Romain Deltour: this scripting mechanism is only about an origin–could be an opaque origin, doesn’t have to be a url.
… opaque origin serializes to null.

Ivan Herman: where do we go from here?.

Dave Cramer: do we ask for help?.

Ivan Herman: we have tried and failed before.
… we have been discussing these things.
… if we come up with a concrete proposal.
… and then check whether that solution is acceptable to the TAG or whoever.
… my knowledge is not good enough to write a proposal.

Romain Deltour: I was supposed to come up with a proposal.
… I can write a summary of issue with possible approaches “paths” to solutions.
… I don’t know enough about URLs and security to know all the plusses and minuses.

Ivan Herman: we can’t go to CR with this stuff open.
… it’s unfortunate that Tess is not around any more, we might ask the TAG.
… and the TAG takes time.
… we have time pressure.

Dave Cramer: could we talk to ping?.

Romain Deltour: could we liase with Anne at WhatWG?.

Ivan Herman: I worry about that.

Tzviya Siegman: talking to Tess would be good.

Ivan Herman: if we have a proposal that romain can put together.
… my first option would be to involve Tess.

Romain Deltour: I can summarize the problem statement.

Laurent Le Meur: tests will take time.
… why don’t we just say that path-absolute URLs are illegal.
… and just update epubcheck?.
… to post an error if there’s a slash at the beginning of URL.

Romain Deltour: path-absolute URLs are a red herring. the issue is with any relative URL really..

Laurence Zaysser: could we have a fifth objective, easy to move to web publication?.

Romain Deltour: it’s about any relative urls. Just dealing with path-relative won’t solve the issue.

See github pull request epub-specs#1725.

Matt Garrish: we have 1725 PR, which forbids path-absolute URLs. Is there any reason we shouldn’t merge that?.
… should we close that? Or integrate it because it deals with part of the question?.

Wendy Reid: have we exhausted this?.

Ivan Herman: to answer matt, that one can go in.

Romain Deltour: +1.

Ivan Herman: using root-relative IRIs is a bad idea for something like epub, where the root url is unclear.

Proposed resolution: Merge PR #1725. (Wendy Reid)

Romain Deltour: +1.

Ben Schroeter: +1.

Ivan Herman: +1.

Gregorio Pellegrino: +1.

Matt Garrish: +1.

Shinya Takami (高見真也): +1.

Dave Cramer: +1.

Brady Duga: +1.

Matthew Chan: +1.

Tzviya Siegman: +1.

John Roque: +1.

Bill Kasdorf: +1.

Wendy Reid: +1.

Toshiaki Koike: +1.

Laurent Le Meur: +1.

Charles LaPierre: +1.

Hadrien Gardeur: +1.

Dan Lazin: +1.

Resolution #1: Merge PR #1725.

3. Testing Update and Discussion.

Wendy Reid: this last segment of the meeting is about testing.

Dan Lazin: 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.

Dan Lazin: https://w3c.github.io/epub-tests/.

Dan Lazin: we’ve built the test framework, and have started making the tests themselves.
… credit for this reporting framework to ivan.
… automatically compiled from all the tests that we check into the github repo.
… (about 57 in total now).
… each test links to the statement under test in the spec,.

Dan Lazin: See example for test references in the core spec.

Dan Lazin: See example for test references in the RS spec.

Dan Lazin: currently links go to the github version of the spec (ie, the editors’ drafts).
… in most of these documents there are expandable drop down that link back to the tests.
… these are hidden in the published version of spec.
… so this works as a bi-directional link.
… we want to make sure every MUST or MUST NOT has tests (but also the SHOULD-s and MAY-s).
… total number of tests should be about 300.
… wendyreid demoed the test writing process, and it only took about 5 minutes for one test.
… the bottom of the test document has the names of the contributors.
… what we are requesting now and help from the WG to fill out the test corpus.
… you can borrow from what is already there to make your own tests.
… this is a contribution guideline - step by step directions on how to make a test for us.
… ivan also made a report of the implementation results for us.
… so far this document is populated with fake data.
… if you are RS dev and are interested in starting the assessment part of the test, you can do so.

Brady Duga: if i decide to publish all these test documents, is that allowed? No IP restrictions?.

Dan Lazin: not that i know of, but i’m not legal expert.

Brady Duga: I was going to put the epubs into the Play store.

Dan Lazin: my concern would be that some of the tests have images in them, and minor assets of that type.
… at the moment the tests are a bit in flux.
… things are being renamed, etc..
… 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.

Rick Johnson: on versioning, github would be the way we’d know if a test had changed, right?.

Dan Lazin: handling re-names in github is tedious, so its not always easy to tell what is update and what is new.
… i’m new here, and there are some weaknesses in the test.
… 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.
… but you’d only be re-testing if you failed.

Rick Johnson: well, and we’d re-test for any test that changed, too.
… is there a document on how to do the test as a RS vendor?.

Dan Lazin: the bottom two sections of that how-to link that i posted earlier contains the information you’d need.

Ivan Herman: we have to realize that we have about a year for RS to do testing.
… the rush is more in populating the test bank.
… to get to official CR phase is that we must show a clear path on how we plan to do testing.
… 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.

Wendy Reid: when I run the tests I’ll probably uploading them to the Kobo server too.
… i can quarantine the test books so they’re not public.
… 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.
… and then if there are changes, it’ll be easier to track that change with versioning.
… if there are updates to files, its not hard for me as RS vendor to update the test in my system.
… i just want to know which tests are done, and which ones i need to re-test.
… so we might give a pointer to the test collection, but a pointer to tests which have been recently updated.

Dan Lazin: we’ve seen a lot of value in proving the process here, has been very valuable.
… if there are RS vendors who have an appetite for getting started, it would be helpful to hear your feedback.
… Alos, when we started we had a tracking spreadsheet - we’ve since dropped this.
… what you want to do to see where tests have already been created are scanning the github version of spec for the test dropdown.
… the areas where we are most looking for help is FXL and MO.
… testing the RS spec is fun and easy, but testing core spec has yet to be tackled.
… lots of cases where the author has to do certain things, and we are still discussing in testing TF how to handle this.
… please join us in our meetings, and maybe we should start a testing Slack.

Rick Johnson: slack channel?? we have w3c slack channels? Pointers, please!.

Ivan Herman: wendyreid i think what you were referring to is like a github release; we should definitely do that..
… If for some of the RS testing means that they have to put test epubs into a public space.
… maybe its worth adding a copyright statement into the metadata of each test.
… probably the w3c copyright into each of those tests.
… maybe this can be automated.
… we wouldn’t use it for the reporting mechanism though..
… Dan also referred that its not always obvious what testing means for some assertions in content.
… similarly we have issues with vocabs in the spec.
… its the kind of testing we have to do in terms of showing that metadata is used in practice.
… collecting data to show that our normative metadata values are actually used by authoring community.
… similarly, what does CR phase mean for a11y spec?.
… not sure how a11y WGs normally do this. Maybe talk to Michael Cooper?.
… but we must have an answer to this before CR.

Rick Johnson: there are a lot of very good, still used, tests that Markus wrote back in the day.
… can that be part of this?.

Ivan Herman: we could roll them in, but not sure how we would use and evaluate those tests.
… the mechanism we have today may or may not be appropriate, currently unclear.
… we may have to handle reporting of these a11y test results may be separate.

Rick Johnson: as a RS vendor I’d love to have a single comprehensive suite of tests.

Ivan Herman: rickj can you share point to the tests you were talking about?.

Tzviya Siegman: i think Marisa handles those tests. And I think those tests are different, because you’re also testing interaction between epub, RS, and AT..

Rick Johnson: sure, as long as we can get all the tests into a single suite.

Tzviya Siegman: and let’s not forget about the a11y metadata user guide.

Matt Garrish: old epubtest: https://github.com/IDPF/epub-testsuite/tree/main/content/30.

Avneesh Singh: i think you’re talking about the old epubtest.org where there were sample content. Now epubtest.org is more testing experience..

Rick Johnson: yes! Those unit tests.

Avneesh Singh: the older tests may help, as those as more aligned with you current testing process.
… those were structured as unit tests.
… we still have those in archive somewhere.
… ivan were you also thinking about how we would prove implementation?.

Ivan Herman: question is what implementation means in terms of a11y spec?.

Avneesh Singh: members here are using it already.

Ivan Herman: so we’d just have to prove that somehow, that the community has accepted it.
… i think mgarrish did some work collecting data about the usage of certain features.

Avneesh Singh: 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.

Matt Garrish: metadata cg: https://github.com/w3c/a11y-discov-vocab.

Avneesh Singh: there is also a group looking into a11y governance that could help.

Matt Garrish: there is a part of the a11y spec that just refers to WCAG.
… and there is the metadata component.
… showing implementation of the metadata component should be doable.

Laurence Zaysser: if there are no errors in the first tab of an ACE report then most of the a11y requirements are being respected.
… there is also another tab in ACE about what metadata is being used.
… so is that enough of a test, maybe?.

Charles LaPierre: 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..

Dan Lazin: 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.

George Kerscher: 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..
… I don’t think we’ll have any issue showing implementation of this.

Avneesh Singh: next year we’re working on updating DAISY a11y tools Ace and SMART to EPUB Accessibility 1.1, so it will facilitate implementation of EPUB accessibility 1.1.

Wendy Reid: 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..
… thank you to all scribes.
… cheers for the wonderful discussion!.

4. Resolutions

• Resolution #1: Merge PR #1725.