EPUB 3 Working Group A11y Telco — Minutes

Date: 2020-12-10

See also the Agenda and the IRC Log

Attendees

Present: Avneesh Singh, George Kerscher, Juliette McShane, Matthew Chan, Laura Brady, Charles LaPierre, Bill Kasdorf, Jun’Ichi Yoshii, Ben Schroeter

Regrets: gregorio

Guests:

Chair: Avneesh Singh

Scribe(s): Matthew Chan

Content:

Avneesh Singh: this is the last call of the year.
… today we have a bunch of issues from github to discuss.

1. Alignment of NAV TOC with spine

See github issue #1430.

Avneesh Singh: alignment is no longer a requirement in EPUB spec 3.3.
… however, it is recommended.
… should alignment be added as requirement in a11y?.

Matthew Chan: .. after discussion in github, it seems we should not make this a requirement.

Avneesh Singh: maybe we can just add a warning at the toc is out of order?.

Charles LaPierre: agreed. There are cases were TOC will not be in complete alignment.
… when this is the case, the technique document should say to add this warning to the accessibility summary.

Avneesh Singh: the technique should recommend that TOC should align with spine, unless there is a real need for it to not align.
… and that there should be text in the TOC that conveys that the toc is out of order.
… and a note in the accessibility summary.

George Kerscher: how would adding a note to the nav TOC work?.
… I would think that somewhere in the book, in the beginning, the presence of multiple TOCs would be explained.
… like an explanation of how to use the book.
… maybe this could be a best practice that we promote?.
… and the accessibility summary would say, “this book is not meant to be read linearly, and there is text that explains how best to explore this book”.

Avneesh Singh: We can have the discussion about technique on a separate call. We’ll give this proposal to Matt G, and he’ll come back with the technique.

Charles LaPierre: also, should we add something to the epub that exposes that sort of disclaimer text to the user as well?.
… but then RS will have to implement that.

Avneesh Singh: There could be a text in the TOC element itself, but this text wouldn’t necessarily be displayed by RS where the TOC appears visually like an expandable tree.

Proposed resolution: We are not having success criteria of aligning nav doc with spine, but we will have a technique for it.. (Avneesh Singh)

Matthew Chan: +1.

Laura Brady: +1.

Charles LaPierre: +1.

Juliette McShane: +1.

Ben Schroeter: +1.

Bill Kasdorf: +1.

George Kerscher: +1.

Resolution #1: We are not having success criteria of aligning nav doc with spine, but we will have a technique for it..

Avneesh Singh: I will discuss this will Dave and Wendy. Will open an issue about maybe having a flag to indicate lack of alignment.

Jun’Ichi Yoshii: +1.

2. Relaxed requirement of alt-text for description in a11y 1.0

See github issue #1441.

Avneesh Singh: if an image is complex, authors should be using long desc or extended desc.
… we relaxed this requirement originally because we didn’t want to overburden authors.
… but over the past 4 years, a11y has come a long way.

Charles LaPierre: for Benetech GCA, we’re seeing all publishers and vendors embracing extended desc for complex images.
… we’re not getting push back.

Bill Kasdorf: That is really good to hear!!.

Proposed resolution: align requirement of text equivalent in EPUB accessibility with WCAG 2.x SC 1.1.1. (Avneesh Singh)

Matthew Chan: +1.

Laura Brady: +1.

Bill Kasdorf: +1.

Ben Schroeter: +1.

Charles LaPierre: +1.

Jun’Ichi Yoshii: +1.

George Kerscher: +1.

Juliette McShane: +1.

3. Clarify credentials need to be associated with certifier

See github issue #1410.

Avneesh Singh: credentials refine certifier, but this relationship is not clear in the spec.
… Matt G suggested that we formalize this relationship.

Matthew Chan: Matt G’s example https://github.com/w3c/epub-specs/issues/1410#issuecomment-724095290.

Proposed resolution: associate CertifiedBy with CertifierCredentials with refine. (Avneesh Singh)

Matthew Chan: +1.

Charles LaPierre: +1.

Ben Schroeter: +1.

Juliette McShane: +1.

Bill Kasdorf: +1.

Jun’Ichi Yoshii: +1.

George Kerscher: +1.

Laura Brady: +1.

Resolution #2: associate CertifiedBy with CertifierCredentials with refine.

4. Adding an icon for a certifier’s credential

See github issue #1434.

Charles LaPierre: with GCA, we have 3 things: 1. GCA as text string, 2. Url to point to the page of the credential, 3. An icon or badge for certification.
… potentially that badge could go somewhere inside the epub content, e.g. on the jacket.
… and then the text string could be the alt-text for the badge.
… we had this come up with VitalSource.
… but we have to give them the notice to surface this info out of band.
… it would be useful if this information could come from directly inside the epub.

George Kerscher: what about if we create a new piece of metadata that is just a link to the badge?.

Charles LaPierre: instead of having it just inside the epub?.

George Kerscher: yes.
… and then we could use the same refines technique.

Avneesh Singh: where is the Url going right now Charles?.

Charles LaPierre: right now it is going to a webpage that has the certification, with the publisher name, and the badge, etc..
… but VitalSource doesn’t want to have to go out to the webpage and look for where the badge is, etc..

Bill Kasdorf: i’m open to these options, but from a production point of view, is that a GCA publisher would just put the badge on the copyright page.
… so that badge might be in the book anyway.

Avneesh Singh: Also, we’ve had issues with external content before, like when the cover was not part of the book.
… if we are moving towards a direction where the badge is already part of the content of the book, and then we just point to it, then there is no problem.
… but if the badge is just somewhere in the metadata, then this is more of an issue.

Ben Schroeter: in general, i want to avoid tailoring metadata towards a specific use case.
… the spec should be agnostic.
… Bill, I don’t think your suggestion is one that we’re going to see come to fruition.

Bill Kasdorf: …and the a purchaser would have to have the book before the logo would be seen before they could but that logo on.

Ben Schroeter: and plus, there are going to be non-accessible versions of the book too… like the PDF, or the print.

Bill Kasdorf: right, i see how that is an issue.

Laura Brady: As a publisher, we do put that GCA statement in all our books.

Charles LaPierre: But the metadata in an epub version is specific to that version, right? It wouldn’t be brought over to a PDF version.
… so having the metadata pointing to an external image, or somewhere inside the epub are both options that seem equivalent to me.
… why would one be a problem, and the other not?.

Avneesh Singh: Okay, let’s explore this more in the github issue and come back later for a resolution.

Charles LaPierre: we could also do both: have 1 badge inside the content, and 1 in an external point URL.

Avneesh Singh: Another point is that content in the epub will remain static over time. If there is a badge refresh, a URL method would keep everything consistent.

Charles LaPierre: right, but then internet connection issues will impact an external file method….

5. META-002: add accessModeSufficient=visual

See github issue #978.

Avneesh Singh: There was a suggestion over on github that when there is text in a book, this should satisfy accessmodesufficient=visual.

Proposed resolution: We will not add accessmodesufficient=visual for text content, instead we will clarify why it should not be done. (Avneesh Singh)

Avneesh Singh: but discussion revealed that text can be consumed via multiple modes.
… so instead, Matt G proposed that there should be a note explaining this concept, and why accessmodesufficient=visual does not apply.
… and why such cases should be covered by accessmodesufficient=textual.

Charles LaPierre: if a book has both images and text and the images are described via alt-text, then accessmodesufficient=textual works, but also accessmodesufficient=textual, visual.

Avneesh Singh: to clarify, accessmodesufficient means that the content of the book can be consumed via ALL the following modes.
… so the comma in that attribute means logical AND.

Bill Kasdorf: somewhere we need to be clear on: 1. that two values is AND (not OR), and 2. that accessmodesufficient property is repeatable.

Avneesh Singh: a lot of this also depends on how you are presenting it.
… e.g. if you are presenting this information in JSON vs XML.
… in JSON this would all be in a list.

Proposed resolution: We will not add accessmodesufficient=visual for text content, instead we will clarify why it should not be done. (Avneesh Singh)

Matthew Chan: +1.

Charles LaPierre: +1.

Laura Brady: +1.

Bill Kasdorf: +1.

Juliette McShane: +1.

Ben Schroeter: 0.

Resolution #3: We will not add accessmodesufficient=visual for text content, instead we will clarify why it should not be done.

6. Reference to idpf accessibility forum

See github issue #1417.

Avneesh Singh: in the IDPF version of a11y technique, there is a reference to a forum that no longer exists.
… for people who have to discuss techniques, where do they post?.
… idea is for people to post directly to the issue tracker.
… there are other options, but github is easy for anyone to find and post on.

Proposed resolution: Refer to epub-specs GitHub issue tracker.. (Avneesh Singh)

Charles LaPierre: +1.

Matthew Chan: +1.

Bill Kasdorf: +1.

Ben Schroeter: +1.

Jun’Ichi Yoshii: / +1.

Laura Brady: +1.

Juliette McShane: +1.

Resolution #4: Refer to epub-specs GitHub issue tracker..

7. Alignment of a11y spec with WCAG 2.1 and possibly to WCAG 2.2.

Avneesh Singh: should a11y just point to whatever the latest version of WCAG is? And not discussion specific versioning of WCAG?.
… alternatively, Matt G suggested that we could provide spec users with an option, e.g. a11y 1.1 + WCAG 2.1 or a11y 1.1 + WCAG 2.2.

Bill Kasdorf: the first option (no specific versioning) is more consistent with other specs.

Charles LaPierre: counter-point, on our technical bulletins, we’re getting pushback from publishers.
… people are worried that they won’t be able to adapt their workflows in time.
… this will be a problem if we try to keep our spec evergreen using non-specific WCAG versioning.

Avneesh Singh: also, US publishers are ahead of the world in terms of WCAG uptake.
… this is important, so we will return to this in January.

Ben Schroeter: Agree that WCAG is a bit of a moving target.
… giving the publishers the choice would probably be better from that perspective.
… there’s always a lag between when a new version of a standard comes out and when it is widely adopted.

Bill Kasdorf: what about keeping our spec version agnostic, but having a requirement that authors report which version of WCAG they are applying.

Avneesh Singh: there are multiple options, so maybe I will open an issue tracker where we can discuss this in more detail.
… next call will be in January.
… we will announce the precise date as we get closer.

8. Resolutions