Meeting minutes
present*
GeorgeK: we have updated the columns in the repo, the question is now we have got a couple of roles in the table. If we were to add all the possible combinations we are gonna have quite a few
Table columns have been updated with: Accessibility Metadata, Priority and Suggested summary
GeorgeK: we want to provide guidance of the first column
… some publisher have confirmance statement in internal standards
… the question is how we structure the columns
Rachel: we are tracking state internal, not a really standard but benefit for us
GeorgeK: so you just use the internal fields internally and not to put in the summary
Makoto: I am wondering if DAISY Japan introduce fields especially for Japan publications we might need to add to accessibility summary as well
GeorgeK: in that case can you put some explaination
Makoto: yes
GeorgeK: so how we can structure the table?
Michelle_: I wonder if we could have external statement and internal statement
… some publisher might want to use certain external statement
CharlesL: I wonder if we could map your needs to see which statement could be internal or external
… one thing is we have a lot of confirmTo statement and we have some issues
… because some of them are referring to internal resources
… I think we need to make it clear
… back to george's question for the WCAG case we can have some general statement
… I don't think we need to expand the table.
mgrrish: the text itself is pretty generic. How we represent the different string metadata?
… I don't think we need lots and lots of different statement but think we might have some basic statement. Only way to tell internal/external we would have to use the refines statement, is the only option we have available programmatically within the OPF.
GeorgeK: so we link the crosswork in accessibilitySummary. If company is produsing this from ONIX then they can generate accessibilitySummary from there since not all epub has this field
… does this sound correct?
GeorgeK: multiple confirmsTo is included in a11y 11 spec?
mgarrish: need to check
GeorgeK: move on to the 2nd item in the agenda
… which group we are going to link to?
… so we got two crosswalk - schema.org and ONIX, schema.org and MARC
… now for example of confirmsTo, we got accessibilityFeature and so on, for the confirmsTo what are we linking to
CharlesL: maybe still IDPF for now
mgarrish: we can use publishing a11y since it's only in the epub a11y right now
GeorgeK: so what do we link to from accessibilitySummary to give people correct confirmsTo?
… is it the EPUB Accessibility specification link (https://
mgarrish: if that is to provide the mapping and confirmsTo then can link to it
GeorgeK: just try how to structure the a11y table
GeorgeK: ok, now we are clear about which crosswalk we are going to link to
… question to Brady, if a book has multiple languages then in accessibilitySummary how do we deal with multiple language? For book with more languages it's going to be complicated
duga: I don't think we need to overengeneer it
… if a book is in English and French and in Canada then if there is any legal reason for it we might have issue there though
… but in most cases we only get one language for a book in the bookstore
… suggest remain silent here since we don't know if that is a true use case
… but I can not make any statement here yet
GeorgeK: ok let's not close this issue yet. We might not want to go to multiple accessibilitySummary and we assume take the first one
Naomi: I agree with not make statement yet. The scope can be very quick snowball
GeorgeK: we get one more issue in the agenda
… when publisher provide contact information for help or feedback do you think we could put it as part of accessibilitySummary?
Naomi: one issue is the hardcoded metadata in epub might be outdated later. Maybe still just email address is good enough?
Rachel: we maintain generic a11y issue email and we included it in book and else where I don't know if needed to put it as part of accessibilitySummary
duga: this is kinda beyond accessibility but we also get all feedback of typo and stuff
… I don't think the contact in accessibilitySummary is very helpful and we might have a lot false positive
mgarrish: I don't know if people look at metadata for accessibility related contact.
… recommend not put in accesibilitySummary
Michelle_: second mgarrish
… might not be necessary for library as well
GeorgeK: ok I suggest close this issue and put minuts in the github link
… next call is June 2nd
… thank you everyone and talk later