Meeting minutes
<gpellegrino> 1 chocolate egg for Brady
ikkwong: Introduce Dan Kimberg from Google who will be the regular attendee
Survey Update
wendyreid: 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
duga: Who will summarize?
wendyreid: Chairs
ikkwong: The link we share will be the anonymized version, the originals will be discarded as they have PII
Issue 2526 - w3c/epub-specs#2526
wendyreid: 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
<wendyreid> Proposed: Update EPUB Accessibility 1.0 to align with EPUB Accessibility 1.1, close issue 2526.
<George> +1
<mgarrish> +1
<SueNeu> +1
<MasakazuKitahara> +1
<shiestyle> +1
<gpellegrino> +1
<duga> +1
<AvneeshSingh> +1
<CharlesL> +1
<wendyreid> +1
<Hadrien> +1
wendyreid: Please vote
<ivan> +1
<Dale> +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
mgarrish: 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
gpellegrino: 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: We are increasing the version for 2 documents, right? So we have to update short names, etc, for both of them
wendyreid: 2 documents?
mgarrish: Yeah, there is also the techniques document
ivan: Can we forget 1.1.1?
AvneeshSingh: We can forget 1.1.1. We wanted either 1.2 or 1.1.1, we decided on 1.2
mgarrish: Do you mean just add this to the change log?
ivan: No, I mean in the generated history. Should it start with 1.1.1 or 1.2?
mgarrish: No we need the history since it is part of the change
ivan: So we need to change from 1.1.1, and I need to tell the webmasters this, so it must be in the resolution
<wendyreid> 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.
<mgarrish> +1
<CharlesL> +1
<duga> +1
<George> +1
<SueNeu> +1
<ivan> +1
<shiestyle> +1
<MasakazuKitahara> +1
<wendyreid> +1
<gpellegrino> +1
<AvneeshSingh> +1
<Dale> +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
wendyreid: I don't think we will resolve this today, but we need to start the discussion now
Hadrien: 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
shiestyle: 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
wendyreid: 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
gpellegrino: 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
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: 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
mgarrish: 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: 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: 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: 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)
wendyreid: 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
CharlesL: 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)
SueNeu: Q about image size in spine
… How does that play into multiple screen sizes or orientations?
… is this percent or em or pixels?
Hadrien: I don't think this is any impact. Same as having images in the xhtml
<ivan> +1 to Dale
Dale: 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?
AvneeshSingh: 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: On the size issue, any lib can extract this from the image itself
mgarrish: 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
wendyreid: 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
<AvneeshSingh> +1 size information prevents reading file for this information.
wendyreid: So there may be some validity to having it in the spine
Dale: Following on SueNeu, 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: 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
duga: I'm just echoing Hadrien, 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?
wendyreid: Good discussion, I will open an alternatives discussion
ivan: 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: 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: 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