<Avneesh> OK Tzviya
+present
<Avneesh> https://w3c.github.io/publ-a11y/UX-Guide-Metadata/
Avneesh: merger of EPUBCG with Publishing CG
... documents will be renamed automatically
... should we wrap up quickly? No, it's fine to let it be a Publishing CG document, don't rush it
Laudrain: EPUB CG renamed Publishing CG. Participants automatically included in the new Publishing CG group
Avneesh: Formatting of documents underway. Gregorio, any issues?
Gregorio: Three main docs plus index linking them. Main docs edited with W3C framework. They are fine.
... the index file has no existing template so we used the EPUB3 spec style
<gpellegrino> https://w3c.github.io/publ-a11y/UX-Guide-Metadata/techniques/
Gregorio: that is the final public style of the index
<Avneesh> https://github.com/w3c/publ-a11y/issues/10
Madeleine: issue is that our doc does not discuss reflow -- when transforming text, it must stay in a single column for low vision readability
... where in the doc can we discuss this? Currently displayTransformability is only part of screen reader friendly but that's not the right spot for reflow issues
<Bill_Kasdorf> font substitution for dyslexia as well?
George: We should separate reflow from Screen reader friendly. it is important for all readers who adjust font size
Charles: displayTransformability should mean reflowable, so should we add a section?
Avneesh: fixed layout can be screen reader friendly
MattG: DisplayTransformability is confusing for epub. It seems more oriented to Word docs. For EPUB, it is the reader tool that controls it, not necessarily the document
... a fixed-layout doc might allow change of fonts etc, so be transformable, but stay fixed in layout and not reflow.
<gpellegrino> +1 for "reflowable" features
MattG: Should we separate reflow from transformable?
Bill: displayTransformability for dyslexia fonts also -- not reflow
<epub3cg-a11y> agree with Bill
<epub3cg-a11y> .
Luc: There are other metadata that convey reflowable. In EPUB, if not marked "fixed" it is "reflow"
Charles: we have ways in both schema and Onix to look for metadata to say "low vision friendly"
... inside epub, look for not fixed layout and for displayTransformability. With those two things we can claim low vision friendly
... In ONIX there is similar
Avneesh: complex to combine this with screen reader friendly
Gregorio: use of fixed units like pixels creates problems with enlarging
Naomi: Agree with Gregorio. Most publishers are using flexible units like em, but some are still using pixels with "important". That causes a problem with relying on reflow
Bill: We are mixing assertions about the epub and assertions about who it is suitable for. We could assert separately for screen reader, low vision, and dyslexia
... How do we most usefully phrase for users? name each group
Charles: In Global Certified Accessible, we check for ems vs. pixels. That is important for low vision users.
... Agree with Matt's suggestion for new low vision section/reflow/whatever the term is
... it would include checking if pixels are specified and important
... and is there something comparable for ONIX about pixels?
... new schema.org value for this feature
Madeleine: Can we expect UI to pull info from EPUB itself about pixels vs need to create new Schema term?
Avneesh: Our scope is the metadata, not the epub file
George: it may be in epub metadata but not accessibility metadata and we should focus on that
... Dyslexia friendly is a nice term, but does it mean only font substitution? That is reading system feature and not book feature
... but dyslexic friendly must also include text to speech.
<Bill_Kasdorf> also changing line spacing, letter spacing, etc. for dyslexic friendly
Gregorio: In ONIX, it is already defined as reflowable and doesn't need new term
Avneesh: We should separate displayTransformability for Screen Reader Friendly.
... We should consider adding Low Vision Friendly and Dyslexia Friendly
... We also have place to get complete metadata, and our UI is only the most important stuff. Are these two new sections important enough to add?
Charles: in ONIX, reflowable term doesn't necessarily support very large fonts such as some low vision users need
Gregorio: So we might also need another term
<gpellegrino> Yes!
Avneesh: are these important
<CharlesL> +1 Important to add this as a new item for Low Vision and Dyslexic if possible.
Madeleine: Yes, they are important and large groups of users
Luc: How can this be measured? What are success criteria for dyslexic friendly?
... Could be deceptive if we can't meet all needs in the range of dyslexia
Avneesh: If we can't get the info from Schema.org metadata and ONIX, then we shouldn't put it in the UI document
Bill: complex to define these two new terms. More practical might be to say if you are making assertions, you should say "there is nothing about this epub that is a barrier for users to transform"
... Not about what's present but what's absent
... and then the reading system has to act on it
Avneesh: Stick to what is in the discovery info
Bill: Exactly
Matt: Focus not on importance but on our expertise and what we can do reliably. We don't currently have expertise on low vision or dyslexia
... In meetings for WCAG Silver, there is more information coming on these kinds of efforts
... They are looking at being able to score accessibility based on which checkpoint is met
Madeleine: ONIX takes the absence approach that Bill suggests -- if it doesn't say it is a pic of text, then it is real text
<gpellegrino> +1 open issue and wait
Avneesh: what should we do? Wait and update this doc later?
Charles: we have enough expertise to tackle low vision, and could get input from Wayne Dick. We may not have enough expertise on dyslexia
... suggest we explore low vision section and not dyslexia
George: if displayTransformability is true, do we believe reflow, font substitution and font resizing are included?
Luc: Schema also includes color choices
<Avneesh> https://github.com/w3c/publ-a11y/issues/9
Avneesh: Propose to add an issue on low vision to explore the possibility
<CharlesL> ACTION: Avneesh to add a new issue to explore Low Vision Friendly
<CharlesL> Madeleine_Rothberg: ONIX does not have an exact 1:1 mapping with EPUB accessibility metadata so unfortunately not all of the accessibility metadata found in an EPUB exists in ONIX at the time of this publication. There are plans to add this metadata to future versions of ONIX but no time frame has been announced. This EPUB to ONIX crosswalk outlines the current overlap in metadata which will get updated as these two specifications
<CharlesL> evolve.
<CharlesL> …, Proposed: add Some Schema.org metadata properties, referenced in EPUB, are descriptions of reading systems and not individual books; this means they will not be appropriate for use in ONIX and will not have a crosswalk. This includes the property "bookmarks" which indicates the ability of a reading system to allow users to set and navigate to bookmarks.
<CharlesL> Madeleine_Rothberg: I agree it may not need to be added.
Madeleine and Luc: not everything will be added
Madeleine: perhaps we should tone this down and not imply all will be added
Luc: why doesn't ONIX want to add things? like hazards?
Madeleine: Don't recall specifics but may be a concern about liability
Matt: Several of the schema metadata features are not EPUB features but reading system features
... Anything in epub COULD be in Onix, at least in theory
Bill: ONIX has a process and updates quarterly. Proposals come from groups like BISG. Not every proposal is accepted.
Avneesh: Do we want something like this in the Onix techniques?
Gregorio: historically, this text is there because we started with Schema and added ONIX. but now they are two different documents. Maybe we don't need this
Madeleine: clarify that both epub and onix do not map all of schema metadata because some is about reading systems not books
<mattg> +1
<Bill_Kasdorf> +1 to Madeleine
<laudrain> +1
<CharlesL> +1
<gpellegrino> +1
<Julian_Calderazi> +1
<Avneesh> https://github.com/w3c/publ-a11y/issues/4
Madeleine: action to draft language for both techniques docs that distinguish book features from reading system features
<CharlesL> ACTION: Madeleine to draft language for both techniques docs that distinguish book features from reading system features
<Bill_Kasdorf> Thanks for staying involved, Luc!!
Luc: I am retiring from Hachette, but I will still be a consultant on accessibility
Avneesh: followup call next week to resolve issues
... same time , 1400 UTC
Thanks all!
bue
bye
exit