Meeting minutes
<Gregorio Pellegrino> 1 chocolate egg for Brady
Ivan Wong: Introduce Dan Kimberg from Google who will be the regular attendee
Survey Update
Wendy Reid: Survey closed over the weekend
… Good responses, but we are still reaching out to a few entities to see if they have feedback
… then we will summarize over the next few weeks
… We have almost 100, and we will share a member only link so we can see them
Brady Duga: Who will summarize?
Wendy Reid: Chairs
Ivan Wong: The link we share will be the anonymized version, the originals will be discarded as they have PII
Issue 2526 - w3c/epub-specs#2526
Wendy Reid: a11y task for has some issues for us
… in 1.1 we dropped summary to recommendation, so we are getting ISO to make summary 1.0 optional
… this change is just doing the same thing for the w3c version
… I just want to make sure we have agreement before releasing the errata
<Wendy Reid> Proposed: Update EPUB Accessibility 1.0 to align with EPUB Accessibility 1.1, close issue 2526.
<George Kerscher> +1
<Matt Garrish> +1
<Susan Neuhaus> +1
<Masakazu Kitahara> +1
<Shinya Takami> +1
<Gregorio Pellegrino> +1
<Brady Duga> +1
<Avneesh Singh> +1
<Charles LaPierre> +1
<Wendy Reid> +1
<Hadrien Gardeur> +1
Wendy Reid: Please vote
<Ivan Herman> +1
<Dale Rogers> +1
RESOLUTION: Update EPUB Accessibility 1.0 to align with EPUB Accessibility 1.1, close issue 2526.
Change EPUB Accessibility version to 1.2 - PR w3c/epub-specs#2790
Matt Garrish: We weren't sure if we needed to update the version number (have to fiddle with all refs)
… but then we made some changes, and we need it for this change, so it makes sense to update to 1.2 now
Gregorio Pellegrino: I added a comment about EU that is currently referencing 1.1
… But I just checked with them and it looks ok, so no red flag
Ivan Herman: We are increasing the version for 2 documents, right? So we have to update short names, etc, for both of them
Wendy Reid: 2 documents?
Matt Garrish: Yeah, there is also the techniques document
Ivan Herman: Can we forget 1.1.1?
Avneesh Singh: We can forget 1.1.1. We wanted either 1.2 or 1.1.1, we decided on 1.2
Matt Garrish: Do you mean just add this to the change log?
Ivan Herman: No, I mean in the generated history. Should it start with 1.1.1 or 1.2?
Matt Garrish: No we need the history since it is part of the change
Ivan Herman: So we need to change from 1.1.1, and I need to tell the webmasters this, so it must be in the resolution
<Wendy Reid> Proposed: Change the version number of EPUB Accessibility and EPUB Accessibility Techniques 1.1.1 to 1.2, with new shortnames epub-a11y-12 and epub-a11y-tech-12, and the publication history listing 1.1.1 as the previous version. Publish a FPWD for both.
<Matt Garrish> +1
<Charles LaPierre> +1
<Brady Duga> +1
<George Kerscher> +1
<Susan Neuhaus> +1
<Ivan Herman> +1
<Shinya Takami> +1
<Masakazu Kitahara> +1
<Wendy Reid> +1
<Gregorio Pellegrino> +1
<Avneesh Singh> +1
<Dale Rogers> +1
RESOLUTION: Change the version number of EPUB Accessibility and EPUB Accessibility Techniques 1.1.1 to 1.2, with new shortnames epub-a11y-12 and epub-a11y-tech-12, and the publication history listing 1.1.1 as the previous version. Publish a FPWD for both.
Discuss bitmaps in spine - w3c/epub-specs#2792
Wendy Reid: I don't think we will resolve this today, but we need to start the discussion now
Hadrien Gardeur: When we look at comics, the vast majority use bitmaps
… by which I mean 1 image per page
… very simple xhtml, no alt text
… We have seen images in spine with fallback to html, or vice versa (fallbacks to images)
… This is largely for performance
… custom comics readers are often optimized for images
… Those reading systems try to guess what is a comic
… While discussing continuous scroll we want those in the xhtml, which makes things more complicated
… But that isn't what authors make, they just want bitmaps
… the xhtml is just an added step
… There are a few ways to handle that, that is the topic for today
Shinya Takami: Japan has a huge comic marketplace
… Many readers just extract images from the epub, and they never display the xhtml
… So even if we added text to those comics, the readers would skip it
… So this isn't really for a11y in Japan
… so if we focus on Manga and comics, this would simplify things
Wendy Reid: We talked recently about fallbacks, but it seems that fallbacks weren't meant for this
… it was to fix missing features
… This seems more like an alternative, maybe we should have a better way of specifying alternatives
… Especially one with a way to indicate what the alternative is for
Gregorio Pellegrino: I agree
… I think introducing this feature as it is may create issues on horizontal review
… I also don't think fallbacks are a solution
… we need a method that meets the exit criteria
… we all agree that descriptions is not a good solution for comics, but it is what we have right now
Brady Duga: I don't know if its true that fallbacks were never designed for alternatives, there was a concept of it at the time
… but there wasn't clarity, it was a possible use, but we could find a better option than fallbacks for this
… I wanted to ask what the explicit solution being propose for this solution, images in spine, with xhtml as a fallback, does the xhtml have the image or just text that says "sorry!"
Hadrien Gardeur: The reality is we are not just allowed to put images in spine with no fallbacks
… so you need a fallback for compliance, and many do that now
… or wrap in svg, etc
… I don't think the spec has to say anything about what is in the fallback
… I don't think can write strong language about what should be in the fallback
… e.g. for continuous scroll, we might want a single document fallback, but we can't do that now
… Comics creators and viewers would like to not bother
… alternatives vs fallbacks might not want to be in this discussion
… there are a lot of edge cases for alternatives, like one to many, atc
… I think alternatives should be raised in a new issue if we want to have that discussion
Matt Garrish: Fallbacks aren't perfect, like having to repeat the same document multiple times
… we almost need parallel spines. Similar to collections
… I don't know what the ideal is
… The inaccessible content I don't understand - you can always do that
… just so long as it is possible then we are good
Ivan Herman: We have no problem with svg in spine, since there is a method for adding a11y info
… but there are bitmap formats that allow adding alternative text the same way SVG does
… e.g. XMP
… I don't know how good the support is for this, but on paper it works
Hadrien Gardeur: That is a possibility, or we can add data to the OPF via refines
… We might want this for other things like dimensions
… SVG isn't something comic authors want to work with
… Not a common output format for comics
… Accessible comments won't really be solved with alternatives
… to really do it we need image fragments with text, audio, taactice, et
… We have recently made a proposal about this
… but this will take a lot of time and effort
George Kerscher: I don't think we will just make comics accessible
… I wonder if metadata in the OPF would say this is not accessible, or if an accessible version exists a way to point at it
… I don't think these will ever be merged (there will be 2 versions of the comic)
Wendy Reid: We can't reduce a11y to alt text, that is just one affordance
… Alt text for a comic can be huge, so it can't easily go in the spine
… we have a challenge as we are limited in certain ways about how to add things to a package
Charles LaPierre: I hear you about alt text, but if we just allowed it wouldn't we be 90% of the way there?
… [breaking up]
… I think as a stopgap the alt text and image size could be a short term win, and work on other solutions in parallel (over years)
Susan Neuhaus: Q about image size in spine
… How does that play into multiple screen sizes or orientations?
… is this percent or em or pixels?
Hadrien Gardeur: I don't think this is any impact. Same as having images in the xhtml
<Ivan Herman> +1 to Dale Rogers
Dale Rogers: In web design there is a lot of effort in separating structure from presentation
… I view the spine as structure, would adding this to the spine blur that line?
… Should we consider if there is a more elegant way to do that?
Avneesh Singh: First, as gpellegrino said, we need to pass horizontal review
… So there has to be a way to inject accessible data
… as to structure, we already have other ways of adding things to the package, but in this case the data should be in the manifest, not the spine
Ivan Herman: On the size issue, any lib can extract this from the image itself
Matt Garrish: We experimented with dimensions in the metadata, but in the end we dumped that
… Not sure why we want to reopen that door. It didn't work the first time
Wendy Reid: You can extract from the images, but we used to have issues where if the viewport size was different across images then only the first was taken
… but this may have been a performance issue
… And yes, you can extract from the file, but it means you have to have it first
<Avneesh Singh> +1 size information prevents reading file for this information.
Wendy Reid: So there may be some validity to having it in the spine
Dale Rogers: Following on Susan Neuhaus, if we grab info out of the image file it is pixel
… For instance, my image may be larger for zooming reasons, and then it will be made smaller for display
… from a design point of view, given just one size is very limiting
… This goes back to telling a story, what can designers/authors do
… I don't want to lose the viewport from the creation side
Hadrien Gardeur: I just want to point out, we removed dimension from OPF, but it is currently forced in every xhtml page
… That is a pain today
… Having the data in the manifest helps with streaming
… , but they problem when it is in the opf is when it is wrong
… So most implementations extract the data themselves, including the size info
… and then the epub is discarded
Brady Duga: I'm just echoing Hadrien Gardeur, the issue with putting it in the spine, it might be wrong, reading systems won't know what to do when it is wrong, who should you trust?
… trust the spine, the xhtml, the image itself?
Wendy Reid: Good discussion, I will open an alternatives discussion
Ivan Herman: To move forward, I would like to see a more detailed proposal
… doesn't have to be a full PR, but I would like to understand the exact changes we are considering
Hadrien Gardeur: Would you like me to keep the same PR, or another, or just a summary?
… It sounds like people may be more open to images with no fallback, but I don't know what that looks like
… for instance xmp, etc
Ivan Herman: Maybe just a rightup with these are the possibilities. Really just a collection of summaries so we can understand what the options are
… I won't be on the next call, but in two weeks I will have that summary. And maybe we can bikeshed on naming more