Meeting minutes
Should we replace "longdescription" accessibility feature, since term extended description is becoming more popular in the standards world? AvneeshSingh]
<AvneeshSingh> https://
AvneeshSingh: longdescription not used in the industry. more widely used is extended description.
George: longdescription vs. extendedDescription. Long description just sounds like it is long alt text and extended description goes beyond that and can have markup. it is more precise and better meaning.
mgarrish: if we rename terms, the print page marker / page break markers, but we had digital only page break which is why we changed that name. when we change these token names I get concerned. If its not a big problem, we will have to address it in the display guide. User end we should not display as "Long Description" but the token in the metadata is just another term or account for.
George: I agree that sounds find. as long as end user facing is consistent.
gautierchomel: before standards calls I struggled with wrong vocabulary I wanted to use longdesc when I put in a longdescription metadata. We need another good practice to explain this.
… time where both terms co-exist which can be confusing but sooner we start the sooner it will end. and must maintain two things and mappings but for folks who enter in the industry and start to use the vocabulary it is much easier if the vocabulary matches the action.
AvneeshSingh: long and extended descriptions are related. short term the discovery CG can discuss this and see what can be done in the description of this.
Morris: work at OCLC, nine months working on MARC side of metadata into World Cat, work with Claire Holliday on the publishing side. I noticed in the mapping between Schema.org and ONIX the long description is mapped to 2 ONIX terms from 196 15-full alternative and 16- visualized data as no graphical. (that is not ideal) when 1 schema maps to 2 ONIX. if its extended or whatever it takes 1:1 Schema:ONIX
… maybe separate terms in Schema.org
gpellegrino: alternative for content and another for the data, I am worried about deprecating the proposal on these terms in the vocabulary. Its really difficult for software to get update and backward compatibility so I propose not to deprecate just add some. this is just machine readable, it will just display to "Extended Description" even if its in the metadata as longdescription.
Simon_M: a lot of publishers keeps asking what does longDescription really means, we don't also know what is a "short description" for alt text, so they don't know what they mean. until we know what the definitions are.
mgarrish: longdescription is ingrained in WCAG, they don't talk about extended descriptions. so not sure who this will help.
… we picked one but it would be better to stay with this term. it makes everything difficult.
… we need to cover the bases what is an extended description vs if it is long. "fuller picture" vs just longer than and an alt description.
Madeleine: crosswalk between Onix/Schema.org sometimes there is more detail in one vs. the other. there are some places where this can't be round-tripped. would liek to know how we can support users. or consider adding more schema.org terms to try to reach a 1:1 mapping.
Morris: when I see longdescription and I see Full alternative description that doesn't ring true for me.
AvneeshSingh: I think we can open an issue in the discovery GC's github repo.
gpellegrino: everything we touch has a big impact, and it takes a lot of time and communication to the larger community. EPUB a11y metadata was always meant for machine readable in all languages in camelCase longDescription does not mean anything to us in Italy for example.
Charles: describes why alt text definition should be revisited Charles will coordinate with Janina and APA as this is a wider than just digital publishing definition of what is an alt text description.
Laura: I noticed some issues where the definitions the schema.org and ONIX may not always apply. explaining the crosswalk better and what the requirements are and where they are exactly make that clear and where they are not exactly the same to point that out.
Madeleine: We would like to see these examples as we weren't given that original task as we were asked just to determin what would be used in ONIX for a specific value.
<Simon_M> There will always be a need for separate metadata values for short and long, no issues with the codes. This is something for EPUB development, to define a technique or set of techniques for long description.
Chris: we have been told that our definitions are already too long, but willing to revise as needed. We never touch the #'s in ONIX, we refine the headings and notes in English, its the definitions refining, we don't change whats in the machine to machine. if there are ways to make it clearer we are happy to look into that.
George: will send introduction to Laura with relevant email contacts. Morris would also like to be included.
In progress consolidated accessibility metadata guidance document.
<AvneeshSingh> kerscher@montana.com
<gautierchomel> https://
mgarrish: the link is no longer valid.
… this is work that Charles started in the Fixed Layout and combined that and another into a new document
… there is stuff from the accessibility techniques and Charles has gone through the values.
… I was just structuring.
<mgarrish> https://
Charles: explained how there are real code examples and then what the metadata would be included.
AvneeshSingh: this is also where we will put in the new guidelines on what would go into the accessibilitySummary.
George: it will be easy to harmonize with 2.0 ux guidelines in the summary that is not machine readable.
gpellegrino: be clear about the scope of this document, and link to other guidelines like for ONIX, and this is for one standard of metadata.
AvneeshSingh: lots coming from 1.1 Techniques. in the introduction for EPUB Accessibility techniques.
mgarrish: Yes, I agree we want this to be schema.org metadata in the EPUB package document. we don't want to go into those other areas.
… could even be updates to the title itself.
gpellegrino: my worry is only on the main title.
Fixed layouts can be display modifiable
<AvneeshSingh> w3c/
AvneeshSingh: there is a lot of discussion on this. what do we want to achive?
gautierchomel: if someone put 2 metadata then there is a possibility that end user could see fixed layout and appearance can not be modified and can be modified. but looks like a bug. We know very few titles, Hachette fixed layout link to see same content as reflowable. Change wording of "Fixed Layout" described in a negative way. i.e. Fixed Layout "Can't be display modified"
<Zakim> George, you wanted to react to gautierchomel
George: reading systems may have the ability to do some customizations. Adobe reader and FoxIt have a reflow button. We are doing the same with an EPUB fixed layout We are trying to express that intent of the format to the end users.
gautierchomel: I think its both use cases fixed layout can be reflowed
gpellegrino: can be accomplished by javascript potentially
… if they claim to be displayTransformability
… if its fixed and does not claim displayTranformability then we will say it can't be adjusted.
gautierchomel: we should open a new issue is there a way to say this is fixedLayout, then we can close this one and reference this one in the new issue.
mgarrish: I agree the issue we originally had is done.
… as we get to the second statement should we just say this is a fixed layout instead of the "not modifiable" might be what is needed.
AvneeshSingh: Yes lets create a new ticket and close this one.
<Simon_M> Is there an IRC etiquette document for this chat?