EPUB 3 Working Group A11y Telco — Minutes

Date: 2021-05-13

See also the Agenda and the IRC Log

Attendees

Present: Avneesh Singh, Matt Garrish, George Kerscher, Wendy Reid, Matthew Chan, Tzviya Siegman, Ben Schroeter, Gregorio Pellegrino, Charles LaPierre

Regrets:

Guests:

Chair: Avneesh Singh

Scribe(s): Matthew Chan

Content:

1. Quick update on progress of explainer document for EU.

Avneesh Singh: gpellegrino, cristina and luc have put together structure for explainer doc for EU
… component for metadata, and for how spec was developed
… this has been sent to EU, and we expect to receive feedback by next week

Gregorio Pellegrino: it is only an informal outline right now to check if structure is okay

George Kerscher: how long is the outline?

Gregorio Pellegrino: not sure, cristina sent it

Tzviya Siegman: eager for the rest of us to be able to see it!

Avneesh Singh: we will share once we receive feedback

2. Add voicing when TTS of titles is not reliable

See github issue #1288.

Avneesh Singh: summarizing discussion up to now in issue, we don’t think many RS support this feature right now
… we propose adding this to best practices, and if we see uptake, we then add to techniques document at that point

Matt Garrish: key is that we need to show implementation
… proves practical benefit over theoretical use

George Kerscher: would this be in metadata or body?

Matt Garrish: in the package metadata
… so you can use the refines attribute with link element to point to audio file of title/author names

Avneesh Singh: so we will wait for mokoto’s feedback

3. alttext for cover image

See github issue #1300.

Matt Garrish: we discussed this too in web publication, publication manifest
… cover img are sometimes used in contexts without html wrapper
… how to do this in package?
… one way is to add an alt-text attribute
… or we could use refines attribute and setup property name, refines could then point the additional metadata field at cover
… but which is more effective?
… each has its pros and cons

Avneesh Singh: whatever our group decides will become a recommendation to WG, not only our decision

Charles LaPierre: if we did the refines method, for the cases where you have cover img in XHTML wrapper (with full alt-text), would that then be duplicated in the package?
… are we worried about that duplication?

Matt Garrish: yeah, that’s one of the downsides
… will be duplication between whatever is in package and what is in XHTML
… and then you’d have to maintain it in two locations
… i was just thinking that maybe a pointer into the document could potentially be a 3rd option
… but yes, could potentially be duplicative, depending on which method we choose

Tzviya Siegman: +1 to pointing to existing image description

Avneesh Singh: it would be nice to have a simpler solution

George Kerscher: so this is used in the bookshelf view (e.g. reading through list of books and this information comes up), as opposed to opening the book and reading it there
… two completely different purposes
… not sure if it would be voiced twice by AT
… some people have also complained about cases where only the text of the cover is conveyed to AT, but the rest of the cover detail isn’t

Gregorio Pellegrino: we will also need best practices for how to implement this
… in a library view, it might be too verbose to have a description of the cover spoken every time

Wendy Reid: the challenge for RS would be surfacing this data
… in the bookshelf view/gallery view, i think most RS are just using title and author
… this is same situation for store carousel
… even with alt-text inside book we don’t often get detailed desc
… like with frontlist titles, covers get updated often (for awards, for movie tie-in covers)
… can see publishers not keeping this up to date

Tzviya Siegman: would there be different descriptions for the actual cover and the thumbnail cover?
… as a sighted user, I don’t process the info in a thumbnail the same way i process the cover in a full view
… so for the pointer based solution, we might not want the description of a thumbnail to be the same as the description inside
… for the books that I work on, where the textbook covers aren’t that exciting, its likely that we’d just want to present basic title/author

George Kerscher: there’s a benefit of alt-text over the refines method, as alt-text is pretty well known these days
… alt-text is intended to be brief
… and then when the user opens the book to the cover, that’s where more detailed desc can be used

Charles LaPierre: in Canada there is a pilot right now to help publishers create alt-text
… the view there is that alt-text for the cover in the book should be more than just title/author
… we probably don’t need all that in the package metadata
… so maybe refines is better from that perspective

Matt Garrish: kind of worried now if we also call this alt-text we will sow confusion
… we also don’t want to compel people to put this metadata into the package even where it isn’t needed if we call it alt-text

Wendy Reid: +1

Avneesh Singh: important to have a short desc for the bookshelf view, and a more detailed desc for inside

Matt Garrish: +1

Gregorio Pellegrino: +1

Tzviya Siegman: have we looked into how each of these different methods of approaching this works with AT?

Charles LaPierre: +1 ask RS dev. Thorium Bookshelf etc.

Wendy Reid: would like to get feedback from RS developers about how this could be done

George Kerscher: when RS developers display this information, they would probably be using the img element with alt-text
… so if we had alt-text available for them, they could just copy the alt-text over along with the img

4. Path forward for sound hazard

See github issue #1302.

Avneesh Singh: some pointers to some parameters for reference:

Avneesh Singh: See CDC document

Avneesh Singh: See Audiology document

Matt Garrish: the sound hazard isn’t actually tied to a specific testable outcome
… there are sound patterns that cause seizures, but not sure if there is any standard for testing for that
… changes in loudness can also cause issues
… right now we have a property called sound that isn’t specific to anything
… what i put in the tracker after is whether we should move away from “sound” towards descriptors of the hazards that can be caused by sound
… e.g. loudness
… e.g. buzzing
… might be more testable
… my concern is that this would be coming from epub a11y spec WG, when maybe we should just be referring out to some other standard
… not sure if we should try to rush something into this revision timeline
… or if we should be looking into this more deeply, consulting other experts, etc.

Tzviya Siegman: before we add this we should refer this to AG group

Avneesh Singh: i have emailed them
… but it would help if you and George can elevate it with them

George Kerscher: we can bring it up, yes, but in a way that makes it clear that we don’t want to drive it
… i’d be happy to close this issue for now

Charles LaPierre: +1 to waiting

Matt Garrish: i’m not an expert, but from what i’ve read it seems like the hazard is very subjective to the individual
… that’s why i’m not sure how easy it is to test for something like this
… makes it especially difficult

Charles LaPierre: maybe having the umbrella category of sound is the best we can do for now

Avneesh Singh: don’t think that this issue is specific to epub, the vocab is from Schema, and the expertise necessary to develop it has to come from a11y experts in this field

Matt Garrish: +1

Avneesh Singh: action item for George and tzviya to raise it with WAI and AG

5. Closing issues 1590 and 1434

Avneesh Singh: https://github.com/w3c/epub-specs/issues/1590

Avneesh Singh: https://github.com/w3c/epub-specs/issues/1434

Avneesh Singh: are there any comments on these?

6. AOB?

Avneesh Singh: wendyreid is there a conflict with our call on the 27th?

Wendy Reid: the WG call is going to be in the evening eastern time
… so no

Avneesh Singh: that is a relief
… okay, thank you everyone!