EPUB 3 Working Group A11y Telco — Minutes

Date: 2021-02-25

See also the Agenda and the IRC Log

Attendees

Present: Avneesh Singh, Matt Garrish, Matthew Chan, Juliette McShane, Tzviya Siegman, Bill Kasdorf, Charles LaPierre, Ben Schroeter, George Kerscher, Gregorio Pellegrino, Cristina Mussinelli

Regrets:

Guests:

Chair: Avneesh Singh

Scribe(s): Matthew Chan

Content:

Avneesh Singh: here is the link to our FPWD
… and the techniques doc

Avneesh Singh: EPUB accessibility specifications: https://w3c.github.io/epub-specs/epub33/a11y/index.html

Avneesh Singh: Techniques: https://w3c.github.io/epub-specs/epub33/a11y-tech/index.html

1. Reporting accessibility conformance

See github issue #1455.

Avneesh Singh: mgarrish if you could please provide an overview?

Matt Garrish: basically, what should we do with the IDPF urls we have now, specific to WCAG2?
… given the flexibility that we have around which version and level of WCAG, i don’t know that we can do a URL approach to this
… we can either come up with a new pattern of URL where you can plug-in the values of your version and level
… or we do a text field following a strict pattern
… it might ultimately come down to whether ONIX requires a URL, or if they can take text strings

Avneesh Singh: it looks obvious that having a single URL conformsto value is the way to go
… or, we could have a text string that has epub a11y version, wcag version, and level

Matt Garrish: the problem is that we allow so many variations in 1.1
… any url that represents would involve a bunch of parameters
… a patterned text string would be easier for humans to work with

Charles LaPierre: first, we want to make sure that whatever we do is backwards compatibility with the current version
… for the old epubs
… second, for the future, the silver TF just presented a future version of WCAG that replaces the A, AA level with bronze, silver, gold
… and rn vitalsource is looking for a particular string, because publishers are putting in their own custom conformsto values

Gregorio Pellegrino: from ONIX point of view, they said that they are okay with adding new values
… but it is uncommon in ONIX to just take text as a value
… if we do ask them to ask code values, they said that they only update twice a year
… so there may be a delay in updating

Avneesh Singh: there was also a comment that a url could be provided in ONIX?

Gregorio Pellegrino: normally in ONIX there is a closed dictionary of values that can be assigned - i.e. a codelist
… you could make it a free text value, which could take a URL
… but if you are using an automatic solution for parsing ONIX, this could be complicated by free text
… for example, in ONIX, you can use URLs to point to supplemental resources
… but not usually as data references
… so are we talking about using a single URL, with various parameters?

Avneesh Singh: yes
… there is also the question of customized accessibility spec, e.g. an optimized publication
… these would also require a customized url

Gregorio Pellegrino: using a text field to store a URL also presents issues with being able to validate

Matt Garrish: i’m not sure we can make our solution compatibility with 1.0
… because the URLs would have to be to W3C pages instead of the old IDPF
… if we are concerned that people are already setup to look for URLs, that could be a consideration to continue using a URL based system instead of going with a text string

Gregorio Pellegrino: so to summarize, we have 3 pieces of data, a11y version, wcag version, and level? So maybe we can have 3 ONIX fields to track this…

Tzviya Siegman: i understand that vitalsource is already setup to use urls, but especially as WCAG advances, this is going to get more and more complicated
… 3.0 is coming, and we don’t know which version of WCAG people are going to be using
… the number of URLs that we’d have to keep track of might not be that manageable
… a text string may be easier to maintain

Avneesh Singh: to clarify, the URL could be reference to a11y spec, and then WCAG could be identified separately

Matt Garrish: also, these conformsto values are for machines to process, not necessarily for humans to read. Don’t forget that people can also put information about a11y in accessibility summary

Gregorio Pellegrino: it’s like namespace in XML, you always get 404 :)

Charles LaPierre: point about validation, if a particular URL references a page that doesn’t exist, that could be flagged by an automatic validator, right?

Matt Garrish: the URLs would be de-referenced, they would just be for machines to parse to extract a11y metadata

George Kerscher: does this meet the publisher’s desire to put their own conformsto string in their publications? Is this repeatable?
… makoto also mentioned in issue tracker that he needs flexibility to add different properties in there

Matt Garrish: there’s no limitation to the number of conformsto

Proposed resolution: Single URL for conformance, EPUB accessibility specs string + WCAG version and level (Avneesh Singh)

Gregorio Pellegrino: +1 to Charles

Charles LaPierre: since you can have multiple conformsto, why not have the 3 as separate conformsto statements?

Gregorio Pellegrino: i like this, for me it is more readable
… also, this allows us to expose real URLs to end users, which will lead to read documents

Matt Garrish: i’m not sure that would work, because there is no real webpage for each level of conformance
… no level A page, level AA page, etc.

Tzviya Siegman: and its not always so easy to say “i conform to AA”
… a lot of books partially conform to AA, missing one thing
… that sort of data sometimes is not so black and white

Charles LaPierre: mgarrish, would we put a refines on the conformsto WCAG version?

Matt Garrish: right… but then we’d have to come up with a new property, with a new set of values

Tzviya Siegman: refines is going away eventually

Matt Garrish: to me, even two pieces seems complicated to ask people to put in their publications

Charles LaPierre: even with vitalsource, who are parsing this, they are seeing maybe 5 different conformsto in some books
… and they don’t know which one to look at for wcag version, which for wcag level, etc.

George Kerscher: does the proposed approach work with ONIX, assuming that we can add new codes?

Gregorio Pellegrino: not sure, I can check with Graham
… they would prefer to have 3 fields in ONIX, but that doesn’t necessarily change our spec, we can still have one single URL in our publications

Ben Schroeter: we need to think about how conformsto will actually be used
… e.g. if we actually expect people to go to that URL, or just a way to designate a11y metadata
… are we making it too hard, on ourselves, on publishers, by being so particular about the level?

Bill Kasdorf: I could imagine a publisher saying @conformsto="VPAT"

Ben Schroeter: when they could just put that info, if they want, into the accessibility summary?

Avneesh Singh: confromsto is for distributors and retailers
… and different states will have different a11y legislation that require conformance data

Ben Schroeter: and we have to give consideration to alternative specifications

Gregorio Pellegrino: i think that from an end user point of view, knowing that a publication conforms to A vs AA makes a difference
… conformsto works towards retailers being able to filter publications by this level

Matt Garrish: so, these things are identifiers, they’re not meant to be surfaced to users necessarily
… a machine is going to parse it before an end user ever sees it

Bill Kasdorf: +1 to Matt

Matt Garrish: our solution should be useful to machines - and either URL or formatted text string meets this criteria

Charles LaPierre: +1 as well to Matt

Avneesh Singh: if we are recommended the triple of data in a single URL, that doesn’t prevent anyone from putting a different URL to their own spec, etc.
… we are just saying that if you are using EPUB a11y, then please use this URL, if not, they are free to use some other value

George Kerscher: can you explain “3 strings in a URL”?

Avneesh Singh: let’s say “single field, with 3 strings” then

Proposed resolution: single field with three strings EPUB acessibility + WCAG version + level (Avneesh Singh)

George Kerscher: +1

Gregorio Pellegrino: 0

Avneesh Singh: gpellegrino to please update ONIX people

Gregorio Pellegrino: yes, okay

Ben Schroeter: 0

Matt Garrish: So: EPUB Accessibility 1.1 + WCAG 2.0 Level AA?

Bill Kasdorf: are we going to be providing specific vocabulary for those three things?

Avneesh Singh: yes

Charles LaPierre: I thought we started off with the URL approach… i’m not as confident with the single text string, with 3 parts
… then we have to explain which delimiters to use between the three parts
… with a URL and parameters, this is already done for us, there’s only the one way to do it

Avneesh Singh: is this a serious problem, do you think?

Charles LaPierre: …not sure

Matt Garrish: we could also enumerate the 6 currently possible strings, with instructions about how to increment the WCAG number
… so its not necessarily that problematic

Charles LaPierre: the idea of providing some pre-formatted examples is a good direction
… with some precautions put in place for future proofing against WCAG 3

Matt Garrish: right, and we can put language in there about replacing A and AA with bronze, silver, etc.

Charles LaPierre: +1

Avneesh Singh: CharlesL, please solicit feedback from distributors/retailers currently parsing conformsto

Charles LaPierre: okay

Resolution #1: single string with three parts EPUB accessibility + WCAG version + level

2. Explainer for difference between audio books, Media Overlays, and read aloud

See github issue #1514.

Avneesh Singh: last meeting we said we wanted to clarify this somewhere, and we were going to leave this to mgarrish

Matt Garrish: i looked at it, and wasn’t sure how this fits in
… if this is just a general primer, i suggest an informative note
… maybe something for the CG to come up with that could be referenced in various specs
… otherwise, we should clarify the purpose behind this, and then include a more narrow discussion in the immediately relevant portion of the spec (e.g. maybe MO)

George Kerscher: i see confusion about this from higher learning people all the time
… i think we should hand this off to CG to write an explainer
… its useful for training people, but it might not belong in a spec

Avneesh Singh: and we could link to the explainer from the spec

Tzviya Siegman: if the goal is to ask the documentation group in CG to work on this, they are pretty busy right now, it could take a while
… i think this could be a very short document

Matt Garrish: i just don’t know that this is a WG note, we could still handle this when we’re doing CG work

Avneesh Singh: this isn’t really related to specs, this is more a publishing issue

Tzviya Siegman: Laura Brady had mentioned that public funding might be put towards writing a11y documentation
… this might fall into that category

George Kerscher: +1

Tzviya Siegman: +1

Proposed resolution: delegate document for difference between Media Overlays, Audio books, read aloud etc to Publishing CG (Avneesh Singh)

Gregorio Pellegrino: +1

Bill Kasdorf: +1

Charles LaPierre: +1

Matt Garrish: +1

Matthew Chan: +1

Juliette McShane: +1

Ben Schroeter: 0

Will: +1

Avneesh Singh: And we will link to it from EPUB accessibility

Gregorio Pellegrino: may we have public funding for buying us coffee? :)

Resolution #2: delegate document for difference between Media Overlays, Audio books, read aloud etc to Publishing CG

3. AOB

Avneesh Singh: the rest of our agenda concerns pagelist, page numbering… not sure if we can cover this in the remaining time

Matt Garrish: no, we probably won’t be able to

George Kerscher: i think we should be attacking this problem on a holistic level
… such that when we close all these related pagelist issues, we close them all with the same solution
… also, should should I raise an issue about virtual page numbers?
… EBSCO is looking at possibility of adding virtual page numbers to any publication they ingest which does not have them

Avneesh Singh: i think so
… we might not be able to resolve it, but there is no harm in documenting the issue
… thank you everyone!

4. Resolutions