-
Notifications
You must be signed in to change notification settings - Fork 4
Minutes of Publishing CG Accessibility Task Force Meetings
Present: AvneeshSingh, CharlesL2, gautierchomel, gpellegrino, Madeleine, rickj, Hadrien
Regrets: Chris Saynor, Chris Oliver
Chair: AvneeshSingh
Scribe: CharlesL2
Meeting minutes
Topic: Next steps for Issue #280: Do we want to display Reason why the publication does not claim to meet the standards:
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/280
Do we want to display Reason why the publication does not claim to meet the standards]
Avneesh: In last call we heard that some publishers may not want this type of information displayed, and there are publishers who want it to be displayed. In Editors call, Gautier suggested separate Conformance Section and Legal Discloser section which could be optional. Since we do not have many publishers in this group, Gregorio suggested that we should take input from Federation of European Publishers, and it is in the agenda of their July 5 meeting.
George: this exemption information is not a conformance claim, we put it there inadvertently. Current draft 3 examples of conformance and removed the example of company claiming a hardship claim.
gpellegrino: I agree, and lets way for legal, and when we get input we can improve it. … , statement ONIX 09 = inaccessible or known accessibility issues. … , where do we place this information?
George: if 09 is present is there the possibility the publisher could have put in other a11y features? … or a valid onix means those other features would not be present.
Hadrien: exemptions - I should have access to this information. if a publication is not accessible I may want to file a report to the regulator. having this information could influence my decision. I agree it doesn't need to be next to other metadata
George: is 09 same as accessibilityFeatures = none. AccessModeSufficient textual is a property not a feature.
Hadrien: I haven't seen that code 09 type of information. Publisher felt confident enough to add to summary but not in conformance or not accessible. Could change, and this was a large set of data I reviewed. … distributors / aggregators for small publishers.
rickj: I agree we don't see any publishers without saying they are inaccessible. but do see some information in the Summary.
gpellegrino: digital comic books of images, accessibility is challenging, Have seem some PDFs with that code for inaccessible.
AvneeshSingh: do we need to worry about it? not interpret 09 at this time for the first draft. if publishers want it we could include it.
gpellegrino: we can skip code 09 comic book for example 09 with our guidelines we will end up with "Unknown" for all required fields. since 09 can add free text can include in the accessiblitySummary section. from the free text in 09 as well as the accessibilitySummary.
Charles: works for me.
AvneeshSingh: so this is the ONIX techniques : AccessibilitySummary (addendum, summary and free text from 09) This will affect only techniques and not principles.
Hadrien: I have never seen anything useful in those text fields.
AvneeshSingh: lets include it in first draft. this is a compromised instead of leaving it out 09 completely. if they start using it a lot we can revise this.
Rickj: +1
Topic: All the accessibility metadata displayed are the claims made by the publisher. How should we convey this fact in our guide:
gpellegrino: should we add "claim" to each item, but everything in metadata is a claim, even the title, subtitle and all a11y metadata, they could claim mathML but there is none in the file itself (copy/paste) … maybe we can add a note that this metadata is from the publisher and in all claims made by them.
gautierchomel: difference with conformance, claiming could be from a 3rd party certifier. … or from a service provider / aggregator etc. … we don't need to specify claim.
rickj: we add a badge "Accessibility claims" for each title with a11y metadata. (Rick is showing his screen)
gpellegrino: I like Rick's approach that they whole section is claims made by the publisher. this book claims to be accepted conformance etc.
rickj: we like the short wording is made localization much easier in 37 languages they support. we are using compact statement but if you hover over it shows the full statement.
AvneeshSingh: How are screen readers coping with hovering over for more information?
rickj: this is just internal currently but yet we will do that testing.
AvneeshSingh: Accessibility Claims then simplify.
gautierchomel: Claim translated in French doesn't work but "statement" does work well. "Accessibility Decoration" good for French / Italy
Topic: Review of further progress in techniques documents.
AvneeshSingh: Onix / EPUB
AvneeshSingh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/techniques/onix-metadata/index.html
gpellegrino: nothing to update we have a PR on conformance but we wanted to wait for the decision about conformance / legal. … Waiting for Chris to finalize the draft and then we can finalize the PR for ONIX. most of the work has been done.
AvneeshSingh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/techniques/epub-metadata/index.html
Charles: holding pattern waiting for ONIX to finalize Conformance / Legal sections.
AvneeshSingh: Thanks, lets meet again in July.
Raw original minutes:
https://www.w3.org/2024/06/27-pcg-a11y-minutes.html
Present: AvneeshSingh, CharlesL, ChrisOliverOttawa, gautierchomel, gpellegrino, Hadrien, Madeleine, Simon_Mellins, wendyreid, RickJ, GeorgeK, MiiaK
Regrets: Chris Saynor
Chair: AvneeshSingh
Scribe: CharlesL, gautierchomel, gpellegrino
Meeting minutes
Topic: Issue #280: Do we want to display Reason why the publication does not claim to meet the standards
https://github.com/w3c/publ-a11y/issues/280
CharlesL: I understand the point of not exposing exemptions. I agree to keep things straight forward with conformity yes or no.
gpellegrino: The EAA aims to inform the end user of the accessibility of the product / service. Transparency is important to be sure we are informing the user. If user knows that publisher is exempted from meeting accessibility requirements, it save a lot of complaints and time of supervising agency in the country.
gpellegrino: I agree to not say why it is not accessible but I see a use case related to the end user raising requests to the authority in charge of survey. So maybe we can find a friendly way to inform.
gpellegrino: there is a difference between a book checked and one not checked.
MiiaK: discussing with Finnish publishers, they seem to expect this exemption to be displayed to avoid complains or unnecessary complains. Especially disproportionate burden.
gpellegrino: this are guidelines, implementers can decide to twist around our recommendations. Also publishers have hands on their metadata.
gautierchomel: 2 use cases. country says no I don't have means to control your metadata I don't want people reaching out, want it to be pre-informed. so they can make legislation regarding that. … the a11y addendum what they want to tell the end users. … recommending to display these will affect what the publishers put into their books/feeds.
Simon_Mellins: I don't see a reason to not display it, I think it's useful for the user and the publisher.
AvneeshSingh: we could find a middle part, soften the recommendation and provide a note that the decision may depend on the market you are serving.
GeorgeK: is there a way to differentiate conformance of those particular items? Can we determine a publisher choice?
gpellegrino: on ONIX, there is no way to saying if the metadata is for internal use of retailers or is to be displayed.
Rickj: we have 32,190 titles that make a WCAG conformance claim
gautierchomel: There is a confusion between conformity and accessibility. … WCAG -aa compliant but does not have Display Transformability. even if it is AA compliant it doesn't work for me. … EPUB made of text except for a cover / logo. but I am a micro enterprise I don't want to check things because I have 1000 books, I want to say I don't know I haven't checked … but it doesn't mean it’s not accessible just that I haven't made the accessibility conformance testing needed. … you may have a file that may not conform to the a11y standard but include a11y features.
AvneeshSingh: You may not put in the conformance statement but do put in other a11y features.
gpellegrino: in schema unknown a11y features you don't know what features are present in the book. you don't know if it conforms or not.
wendyreid: is this information useful is what it comes down to. Retailers need to know this information but maybe not for the user will find useful or valuable.
wendyreid: there is a way in schema and ONIX to inform about the exemption. As a retailer I can see it and I’ll trust it. For the user, is it of use? Few users understand conformity. As a reader, do I really care that the publisher is a micro enterprise? D I even understand what this means? I don't think it is of interest for the end user.
GeorgeK: in the principles, we can put a note in the details area that says when the publisher claims exemption, you may choose to display it or not. And we should change the wording unknown accessibility into unknown conformance.
rickj: I get uncomfortable to saying something is or is not accessible. I don't want to make a judgement, I prefer to stick with what the publishers claims or not.
gautierchomel: is it the publisher is claiming is not meeting conformance, but still have some accessibility. There might be chances to be accessible. … 09 code is not about conformity but is more about that the book may have some a11y issues.
AvneeshSingh: It looks we are OK with softening the exception piece a little and mentioning that retailers can show or hide this information based on their market and expectations of publishers they are serving. We can do further word smithing on editors’ call next week.
Topic: Review of further progress in techniques documents.
ONIX: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/techniques/onix-metadata/index.html
gpellegrino: we are working on conformance, in a wait state since we have to fix the principles (see previous discussion)
gpellegrino: one other point is additional accessibility information. Chris opened numerous GitHub issues to check which are already used, and for each not used, he created an issue with proposal to ignore it or to add it to one or another technic or to put it in the Additional accessibility information section.
https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/techniques/epub-metadata/index.html
CharlesL: we are ready to merge EPUB techniques related to accessibility summary. Like for ONIX, we are waiting this discussion about conformity to be fixed so we can follow up.
Topic: Further updates to the principles document.
https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated
GeorgeK: I created an introduction and made the abstract more aligned with the specifications. Abstract is smaller now, like an abstract has to be. I will give a PR for the conformance section next.
Raw original minutes:
https://www.w3.org/2024/06/13-pcg-a11y-minutes.html
Present: AvneeshSingh, CharlesL, gautierchomel, George, gpellegrino, Hadrien, Simon_Mellins, ccarr, JonasLillqvist, James_Y
Regrets: Madeleine, Chris, Christine.
Chair: AvneeshSingh
Scribe: CharlesL
Meeting minutes:
Topic: Further updates to the principles document for issue #271:
AvneeshSingh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated
George: annotation appears a couple times "Ruby" should be Markup. … should lang of document be en-us? … MS word suggests a dozen edits, commas etc. … will make those edits after this call. … took out repeated section in Conformance.
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/271
George: , unknown examples added, and metadata not present.
… pending question about 3rd example publisher would want this info about exemption to a11y.
Avneesh: Gautier has an outstanding action item to talk to publishers about this issue.
gautierchomel: I think we should put en-us for the language. Should ask Ivan. as most documents are just "en"
Avneesh: we can ask Matt
George: problem with using "annotations" does the book contains annotations in the text. we don’t' want to refer to those like "Annotations - Alice in Wonderland" we are not talking about that. Ruby Markup is just as clear as Ruby Annotations.
Avneesh: Any Japanese colleagues on the call? Maybe Ruby-Annotations perhaps is more widely known?
Gregorio: Discoverability Metadata has schema.org and in the crosswalk. … Full Ruby Annotations is the term. From the other documentation.
4.2.7.1 fullRubyAnnotationsIndicates that ruby annotations [JLreq] are attached to every CJK ideographic character in the content. Ruby annotations are used as pronunciation guides for the logographic characters for languages like Chinese or Japanese. They make difficult CJK ideographic characters more accessible. If some but not all CJK ideographic characters have ruby annotations, use the rubyAnnotations value.
George: should I do Ruby-Annotations to link it together?
Avneesh: I think that could help.
Topic: Review of further progress in techniques documents:
AvneeshSingh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/techniques/onix-metadata/index.html
gpellegrino: there are no huge updates on ONIX side, small fixes, solving issues raised. … conformance section is PR we have a draft we are refining as it is complex. and additional accessibility Info with help from Chris. which metadata should go in this section and all metadata is present in our techniques.
AvneeshSingh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/techniques/epub-metadata/index.html
Charles: In EPUB metadata, mirroring the ONIX techniques just a couple steps behind.
George: Chem on Image then chemical formula is displayed on image to make accessible, alt text , long description … if it is MathML markup and chemistry then they wouldn't have chemOnImage
Charles: We don’t yet have that there is Chemistry defined using MathML in the EPUB Schema.org metadata.
George: Is this an issue for that community group?
Avneesh: Yes, please file that with the Vocabulary group.
George: Ok I will do that.
Topic: Issue #269 : Additional accessibility information - level of detail in Display Techniques:
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/269
gpellegrino: in this section this is a catchall for all metadata not previously represented. Chris is starting this work to find what is missing. … question is: How much we want to go into detail. How much is this metadata used in publishing? should we substructure this section or just list them? … Chris proposed some structure
gpellegrino: would be nice to know about tactile Graphic, TactileObject etc. since meaningful metadata should be present in the other sections.
Charles: the new EBraille format for braille format will be using that metadata.
AvneeshSingh: EBraille will be used by libraries serving people with print disabilities, at least for now.
gautierchomel: we should not over engineer this, but we have to keep in mind more specific info will be needed. France National Library to have all the born accessible EBooks and collection for copyright exemption. There will be need to extend this work. Stick to what is on the display guide with short list of additional metadata. … not specific to a specialized collection.
Avneesh: could be a huge list if we keep everything that is in ONIX … could add a few examples for each section, not the entire list.
George: some of the ONIX codes are embossed braille / paper Braille. Should we put a note in the principals that some additional metadata described below are libraries serving people with alternative content and those context but don't expect to be used in mainstream distribution?
Avneesh: proposed a generic note if there is metadata is needed for your specific audience then you can add this, but it would be up to the implementer to determine what is important for their customers.
gpellegrino: not for special edition and not for paper books, we need to keep this in mind. I think we already wrote something in the introduction, so it should not be needed in the additional metadata section
Avneesh: we can provide updates in this Issue since Chris is not in the call. to keep it simple and let the implementers figure out what is needed for their audiences.
Topic: Issue #266: Clarifying the term "structured navigation" for end users
AvneeshSingh https://github.com/w3c/publ-a11y/issues/266
gpellegrino: two issues: structured Navigation that is not a great term for non-technical users. what would be a better term? to navigate through semantic elements. … Matt suggested navigate by Headings, and Avneesh added, pages, lists, figures etc. … Others have added additional suggestions in that issue.
George: Structured navigation is it clear "book Navigation?"
gautierchomel: structure as a sighted user does not mean anything. how assistive technology will interpret the book and allow for logical flow. … like saying for a paper book that the pages are in the normal order. so we should try to define this concept.
gautierchomel: book will be correctly interpreted by a Reading system.
gpellegrino: correct reading order is a separate feature.
ccarr: Structural Navigation is that the same term in ONIX or are they using "structured" it’s the same term
JonasLillqvist: https://ns.editeur.org/onix/en/196/29
JonasLillqvist: Next Previous Structural navigation
ccarr: structural navigation was chosen as it is the most broad.
AvneeshSingh: so we should leave it as it is.
George: maybe change to "Structural" not "Structured"
gpellegrino: Examples should be given, by headings, pages, etc.
George: Book navigation by book constructs, table of contents, we don't know how often we get list of tables, figures.
gautierchomel: action is performable, by a screen reader.
AvneeshSingh: not only defined by screen readers, read-aloud
gautierchomel: user agent is the correct term but not understandable by average user. … book element can be identified and accessed by AT or RS.
AvneeshSingh: We should be careful about AT / reading system features and the capabilities enabled by the content, we can wordsmith in editors call.
George: Should I give a PR and we can refine it there?
AvneeshSingh: you can do a PR George that is fine. we can update issue tracker
Topic: Issue#265: Clarifying the term "pagelist" for end users
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/265
gpellegrino: PageList is the technical element in EPUB to the print page number. but PageList might not be understandable by end users. the effect of the page list "goto print page" as suggested by Matt, Reference to print pages by Gautier, and others as suggested in the issue.
George: page list enables goto page. but is also a link to that spot. it is content. … it is exposed by the reading system. so goto print page number.
James: I would say goto page number because it may be virtual. … A page list enables users to coordinate their reading with a statically paginated version." … we do have pagebreakMarkers as an accessibility feature already
George: I think "Go To Page" is the key point here.
gpellegrino: saying only page navigation is not enough. You have pages and you go from one to the other. the actual issue here is synchronization is a substitute of the print version. we need to provide this information.
JonasLillqvist: string used in the techniques Navigation by ... feature for this is page list. my suggestion was to use maybe "static page numbers" or page numbers. so we get the navigation and page numbers and should be understandable.
AvneeshSingh: issue with pages two kind of pages, the reading system will show "screens" as pages only page navigation or goto page is ambiguous are we referring to page makers or screens.
George: we don't have navigation by screens, only by page list virtual or print book synchronized. that is what the content provides. … Term I got Enables navigation by page numbers.
AvneeshSingh: any downside?
Charles: works for me.
AvneeshSingh: provide this term in the issue tracker. we can wait for comments. people like "Page Numbers" so this looks good.
AvneeshSingh: Thank you everyone. Let us meet in 2nd week of June, June 13.
Present: AvneeshSingh, Bill_Kasdorf, ChrisOliverOttawa, gautierchomel, GeorgeK, gpellegrino, Madeleine, rickj, Chris
Chair: AvneeshSingh
Scribe: gautier.chomel
Meeting minutes
Topic: How to facilitate discussions for helping implementors?
AvneeshSingh: we start with agenda 3. How to facilitate discussions for helping implementors? as rick has to leave later.
AvneeshSingh: do we want to take time to discuss with implementers? Out of these call.
AvneeshSingh: what is the best way forward to monitor and help implementors.
gautierchomel: in France, one implemented for book shops, one is to do it by September (that covers bookshop portals). Libraries we have no date yet.
rickj: As implementers we may want to discuss during this meeting, with all of you. Maybe the process is to clearly schedule agenda items. I would prefer to avoid to have separate meetings.
AvneeshSingh: OK. The implementors should open GitHub issues or send an email. Then we will figure out which of the questions should be discussed in this broader group meetings and which can be taken in editors’ meetings.
Rickj: +1
GeorgeK: How to convey this information to implementers.
AvneeshSingh: I can send an email to Publishing CG. But, for the implementors who are not in Publishing CG, we need to rely on our contacts to reach out to them.
Gpellegrino: +1 to George: make a call for implementers
gpellegrino: we can create an issue to ask for feedback so we can have a list of implementers and questions. Still they can create a new issue, but we can have a main issue to track things.
gautierchomel: we'll probably diversify feedback collection, including information webinars when the documents are publics and direct contacts.
Topic: Further updates to the principles document for issue #262
AvneeshSingh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated
GeorgeK: this are clarifications for cases where an implementer want to always display something for all information and other edge cases related to unknown values because metadata are missing.
GeorgeK: I think we can still do things a bit better for Hazards. the rest in in good shape.
rickj: what if we have claims being made in key information, but not sufficient metadata to be sure (example, some claims about navigation but not sufficient to be sure of the statement).
rickj: I will write it up as an issue so we can discuss.
Topic: Review of in-progress techniques documents
AvneeshSingh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/techniques/onix-metadata/index.html
gautierchomel: the Navigation (4.5) is now published. Chris is working on Additional accessibility information and we keep Conformance for the end.
Chris: I am note sure about the level of detail to inform for additional information.
Rickj: I have to leave the call. Thank you for adjusting the agenda to accommodate my schedule.
Chris: I'll create an issue for that so we can discuss and have a feedback from the group.
GeorgeK: do we envision we can remove the less important, non used or implemented?
AvneeshSingh: We need further feedback to achieve it. The accessibility metadata that we felt is important is already placed in their respective categories.
AvneeshSingh:We have covered all the agenda items, let's continue discussions and work thru the GitHub.
Raw original minutes:
https://www.w3.org/2024/05/09-pcg-a11y-minutes.html
Present: AvneeshSingh, Bill_Kasdorf, CharlesL, gautierchomel, gpellegrino, Madeleine
Chair: AvneeshSingh
Scribe: gpellegrino
Meeting minutes
Topic: Review of in-progress techniques documents:
AvneeshSingh: let's start with the update on ONIX
AvneeshSingh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/techniques/onix-metadata/index.html
gautierchomel: on the ONIX techniques we've added charts, diagrams, accessibility. summary and Pre-recorded audio … for accessibility summary: in ONIX there are two codes for that (one for the "old" way to intend accessibility summary, one for the "new" way: the idea that should not say the same thing that are already expressed by machine-readable metadata) … so our proposal is that if in a record there is both the accessibility addendum and accessibility summary, only the accessibility addendum should be displayed … second thing is to identify the language in which the accessibility summary (or addendum) is written … to pass it to the assistive technologies
AvneeshSingh: any comments? other items are "Charts, diagrams, and formulas" and "Pre-recorded audio"
gautierchomel: sure, all the text is there, and it can be reviewed
AvneeshSingh: yes, we can get feedback via the mailing list or via the issue tracker
AvneeshSingh: Charles do you have any update on the EPUB metadata techniques?
AvneeshSingh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/techniques/epub-metadata/index.html
CharlesL: we are using the work done for ONIX and mirroring that in the EPUB metadata world
CharlesL: the conformance may be tricky, but let's see
Topic: Issue #251: Principles document examples for nonvisual reading:
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/251
Madeleine: the original issue was that examples in the Principles document for nonvisual reading were not aligned … now it's ok, so I think now we can close it … but there is still a question about aligning examples in the principles document with examples in the non visual reading … ok I'm closing this issue
AvneeshSingh: question: maybe there cases where the order may differ from ONIX to EPUB metadata?
gpellegrino: I think that trying to align the order in the techniques and in the principles it doesn't make a lot of sense … the goal of the documents are different … the order may even differ from ONIX to EPUB
CharlesL: I agree
Madeleine: I agree too
Topic: Issue #260: Need to harmonize Principles and Techniques on Non-Visual Reading:
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/260
Madeleine: another thing is about the "unknown" value. Is it meaningful? Do we need it?
gpellegrino: Principles states that some values can be hidden if null (unknown), but techniques must provide what to say in such case for implementers who want's to display something.
CharlesL: we can add a note in the principles to explain why order can change in techniques
AvneeshSingh: yes, I think that we can remove the "unknown" in the principles document, and leave it in the techniques
CharlesL: er may add a note about the order of the examples in the principles document
gpellegrino: I agree with Avneesh, but there may be cases where we have to say it in the principle (for the three key informations).
AvneeshSingh: yes for the three key information that should always be display, we'll leave the unknown
AvneeshSingh: so: for the key information that can be hidden, we remove the "unknown" for the principles and leave them in the techniques, with a note telling that the key information can be hidden
Topic: Issue #256: Align Hazards examples:
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/256
gautierchomel: the problem here is that we don't have examples for the extended version of all the hazards … I made a proposal in the ticket
Madeleine: how many variants of hazards do we have?
Maybe we can elevate the flashing hazard
and then add another statement about the less common ones
CharlesL: this is tricky … I think that if there is at least one hazard we should display all
CharlesL: yes, I think we can have information about multimedia in eBooks … I like the idea of displaying something only if there is a hazard
AvneeshSingh: I agree we should not get in too much complex specification here
gautierchomel: Yes, I think in most cases we'll not have hazards … I would add a note telling that hazards can be displayed both concatenated and un-concatenated (as a list) … maybe we can also update the section about filtering … to suggest that in some cases filtering for different types of hazards
Bill_Kasdorf: I'm about uncomfortable with under specifying, and to hide information … I think a lot of publishers may use the "unknown" value … and it should be displayed
AvneeshSingh: we have a problem since not all hazards are specified, for example what does it mean an audio-hazard?
gautierchomel: the proposal is not to hide hazards, is only to being able to manage this section both concatenated and as list
gpellegrino: I suggest to check techniques that are clarifying our intention. Only EPUB with no Hazard metadata will have no information displayed.
CharlesL: can we tell if there is multimedia in the eBook?
AvneeshSingh: We should think about it, if we can get it from metadata. We should not go in a path of parsing the content of the EBook.
Madeleine: +1, as long as we can trust that metadata, which I guess we have to do
gautierchomel: I like this approach … I would like to Digg into it … to check if there is multimedia before displaying it
AvneeshSingh: in ONIX there is a way to tell if there is audio or video in the EPUB
gpellegrino: we may dig into a rabbit hole
Topic: Any other business:
gautierchomel: I'm trying to setup transifex, I've asked them but they say that we cannot use it for free, since being part of W3C is not for free
AvneeshSingh: ok, let's continue with the JSON files until we have the tool setup.
Raw original minutes:
https://www.w3.org/2024/04/25-pcg-a11y-minutes.html
Present: AvneeshSingh, Bill_Kasdorf1, ChrisOliverOttawa, gautierchomel, George, gpellegrino, Hadrien, Madeleine, CharlesL, Chris_ED
Chair: AvneeshSingh
Scribe: gpellegrino
Meeting minutes:
Topic: Review of in-progress techniques documents:
AvneeshSingh: we had a lot of merges in the last week
George: I worked in the principles document, based on Madeleine comments
Gautier.chomel: https://www.w3.org/WAI/EO/wiki/Minute_Taking_Tips
George: do I have to add unknown for all principles?
gpellegrino: no
AvneeshSingh: if there is no metadata for hazards I think it is better to hide it in display.
George: if there is the information it will be explicit
Topic: Proposal for ONIX technique for Charts, diagrams, and formulas:
AvneeshSingh: https://github.com/w3c/publ-a11y/pull/257
Chris_ED: the proposal we check if there are charts or diagrams in the publication
Gautier.chomel: https://rawcdn.githack.com/w3c/publ-a11y/1abe0943cbc2bbfe3d35c88b90f0125f383336dc/UX-Guide-Metadata/draft/techniques/onix-metadata/index.html
Chris_ED: I also check if there are Math formulas and chemistry formulas … if some of these are present I check if there are alternatives (extended or data) … if formulas are present I checked if they are in accessible formats
gpellegrino: we have the last instruction for telling when there is a formulas or chart or chem, but not the accessible way to express it … is it ok for you?
Madeleine: yes, I think it is ok to have all them together at the end
Chris_ED: I think it is the most used way in ONIX
gpellegrino: the statements we check if there are formulas and if they are accessible … maybe there is no need to double check if there are formulas in the EPUB
Chris_ED: in ONIX we have a way to say that chem can be expressed both in ChemML and MathML … we are developing a validator for checking that if you say that you have accessible formulas, you also have to say that you have formulas in EPUB
Madeleine: yes, maybe we may have some records saying that there are accessible formulas, without saying that there are formulas at all … so maybe as Chris suggested we may change the first four instructions to check only for presence of accessibility metadata
AvneeshSingh: I would prefer the simplified version
George: I'm afraid that publishers think they have to do extra work for accessible math (apart from MathML)
Chris_ED: "accessible math" is displayed only if we have MathML or LaTeX
AvneeshSingh: I'm aware of ChemML ... never seen it used for accessibility.
Chris_ED: Yes, we have it, but not used … a lot by publishers
gpellegrino: I'll update the PR
Topic: Any other business:
AvneeshSingh: I think some developments happened in IFLA?
ChrisOliverOttawa: It started as an initiative last summer … the idea is to have the whole library community onboard … libraries would like to leverage on the work done in the W3C … in the libraries we have to manage born accessible, remediated, printed books … so we had the idea to start a network within IFLA … it should be approved in April … there is already a lot of interest, with over 60 people … a lot of them have IFLA affiliations, but 30% of them are from the disabilities associations … Gregorio joined the network … we're creating working groups, there will be a crosswalk working group … 4 working groups: general principles, mapping and crosswalk groups (to reuse metadata), best practices and display, vocabulary … for sure the work done within W3C (mapping, display guidelines) would be a starting point for our work
AvneeshSingh: I think that having a sync between our principles document and the IFLA one is important
gpellegrino: I think the scope of the two documents are slightly different
ChrisOliverOttawa: right, it's more high level, also political, but for sure having a sync is important
ChrisOliverOttawa: we have representative from different stakeholders, normally when we publish document than it is reviewed by people from all over the world
who is interested can join the Basecamp group
AvneeshSingh: you have done a great work with the MARC crosswalk. Will you start with that?
ChrisOliverOttawa: we'll use that as a starting point, we'll also have people form UNIMARC
Bill_Kasdorf1: at the end of your work, will this implementation be on the side of libraries or of vendors?
ChrisOliverOttawa: the work should push this idea: if the accessibility metadata is stored, then they should be displayed
we have two use cases: metadata from publishers and local metadata for remediated files
Bill_Kasdorf1: I'm going to work on an NISO WG for defining metadata about remediation … we'll use what is already available, so not to reinvent the wheel
AvneeshSingh: the important thing is to be in-sync.
Raw original minutes:
https://www.w3.org/2024/03/28-pcg-a11y-minutes.html
Present: AvneeshSingh, Bill_Kasdorf, CharlesL, ChrisOliverOttawa, George, Hadrien, Madeleine, naomi, MattGarrish
Chair: AvneeshSingh
Scribe: CharlesL
Meeting minutes:
Topic: Further updates to the principles document:
AvneeshSingh: Lot of work has been done with Principle's and techniques documents
AvneeshSingh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated
George: We have reordered the main items to be: Visual Adjustments, Support for Non Visual reading followed by the Conformance. those are recommended to always be shown. the rest in the order they are in. Next up : how to present the Hazard information. since there is an additional "unknown" if the publisher doesn't know if there are any hazards or not vs. the metadata is missing which also implies unknown hazards. Is there a difference? Thoughts welcome. … also improved the introduction which shows the workflow which Charles helped with the details describing the image.
Bill_Kasdorf: one difficulty lack of understanding of what hazards are. … by the content creator, it is subjective
George: not well defined in the W3C. no decibel values for sounds etc.
Bill_Kasdorf: which prompts for "unknown."
Charles: is there a real difference with "unknown" or missing?
naomi: you can say you don't know about any hazards. the media content exists, if the book has audio content but doesn't have any visual hazards, but can't say about the audio. … does not have those media hazards. they can leave the other two blank. … if anyone is missing it is unknown. would behave the same as if its missing from a user perspective.
Madeleine: when we defined the hazards list there were certain sounds but not well defined user subjective. motion hazards if any rapid scene that would be a hazards any rapid motion.
Charles: we don't have specific unknown hazards for sound, visual etc. so unknown and missing are really the same.
AvneeshSingh: if it’s unknown or no metadata is the same for the displaying it point of view.
Bill_Kasdorf: I appreciate what Naomi and Madeiline has to say. Maybe we should add those 3 unknown hazards which would be useful.
George: you can always add the specifics to the accessibility Summary. If everything is unknown but individually you could state that.
AvneeshSingh: we don't have individual hazards for unknown, but should we do it? but for now we should focus on the display. We don't have a good way to specifying hazards since it is very subjective.
Madeleine: the goal of this document to advice how to display this metadata. do we have a document how to write this metadata.
AvneeshSingh: we will treat unknown and missing as the same for now. Guidance for writing metadata should be a separate track of work, for example George and Charles has written guidance on writing AccessibilitySummary.
Matt: we already have those 3 metadata for unknown Sound, motionSimulation, and flashing hazards. In fact Charles opened this issue in past in schema discovery metadata CG.
Madeleine: we should add an example based on what Naomi has stated about author having only audio but not sure if it has any hazard or not.
Charles: reviewed the 1.1 Publisher metadata ecosystem diagram.
https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated#metadata-ecosystem
Topic: Review of in-progress techniques documents:
AvneeshSingh: any thoughts? No k.
Madeleine: I did add a new issue for the principles document.
https://github.com/w3c/publ-a11y/issues/251
Madeleine: detailed example had 4 sentences, and compact version had 3, and I think items may be swapped.
Charles: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/techniques/epub-metadata/index.html
Charles: recapped Hazards and Visual Adjustments.
George: we revised the text for Appearance modifiable not known.
AvneeshSingh: we can discuss with the editors about unknown vs. missing hazards.
George: in techniques we always use the compact language should we also use the detailed version? do we need both in terms of the principals? or in the Techniques?
Charles: we should ask Rick who isn't here.
Topic: Issue #237: PDF crosswalk and techniques:
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/237
Charles: Reviewed the github issue.
AvneeshSingh: will PDF use the schema.org accessibility metadata. would reduce the need crosswalk, would be simpler. … I will comment in the github issue. … ONIX side for PDF as well.
Topic: Communication and promotion of the User experience guide:
George: I brought this to the BISG and had DAISY people join their a11y metadata group. to get that in front of them. … we can talk about how to promote this as we move forward. I think folks need to know about it now even though it’s not finalized yet.
AvneeshSingh: principles are really good and many would benefit from seeing this even in this editor state.
… next meeting 28'th of March
Raw original minutes:
https://www.w3.org/2024/03/14-pcg-a11y-minutes.html
Present: AvneeshSingh, Bill_Kasdorf, CharlesL, ChrisOliverOttawa, gautierchomel, gpellegrino, Hadrien, Naomi, rickj, wendyreid, GeorgeK
Regrets: Christopher Saynor
Chair: AvneeshSingh
Scribe: CharlesL, gautier.chomel
Meeting minutes:
Topic 1. Review of in-progress techniques documents:
AvneeshSingh: Gregorio and Charles have done techniques drafts.
AvneeshSingh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/techniques/onix-metadata/index.html
gpellegrino: regarding ONIX techniques, first example concerns Visual Adjustment. We found that best approach was to use XPath to define metadata we're looking for. That's why we defined 2 common functions (see section 3) to prepare and query the metadata... … then each technique is in 2 parts, one variable setup and one instructions...
gpellegrino: additionally a detail element "understanding..." gives details on each variable
CharlesL: this is the work in progress link for schema.org techniques.
wendyreid: I understood this document as guidance for publishers to know how their metadata will be used. It looks complex.
Bill_Kasdorf: +1 to Wendy
gpellegrino: principles document is targeted at publishers, techniques for who consume, ingest and display metadata.
rickj: yes, it works for us and our needs. Nice work, well usable to us.
CharlesL: I think additions will be needed in variable set, we'll iterate while writing.
gautierchomel: We should indicate the audience … , user oriented, we are not provided useful information for searching, yet. … dictionary of metadata would help for publishers. "does your book have images? Yes? Does those images required to understand the content? Does your images have alt text etc. at the end so you can get what ONIX metadata for your book. Guidance for publishers should be added but this is a separate document potentially.
AvneeshSingh: SMART has this tool. for metadata for OPF / ONIX
can a link to the principles document be added to the transcript
Sure thing Rick, good idea.
wendyreid: that helps understanding the scope of the documents. Principle and techniques are deeply linked, and giving a clear view to the publisher is maybe missing.
Wendyreid: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/
Bill_Kasdorf: +1 again to Wendy
Rickj: perhaps a resolution to w3c/publ-a11y#199 will help (having an illustration)
wendyreid: plain language description of what the algorithm do may be of use too.
AvneeshSingh: The explanation is in the HTML details element after the algorithm. One can expand the details to read it. What we can do is to move the explanation above the algorithm. we'll discuss that in editors call and see what we can propose.
wendyreid: I think it's of use for publishers but also to implementers.
rickj: a visual to connect dots may help too. We've discussed that last year.
Hadrien: during accessible publishing summit organized by NNELS in Toronto, demonstrations of users showed confusion in the audience about wordings like "screen reader friendly". Recommendations highlighted that this work on accessible metadata is of use for a lot of people (like being able to use TTS).
AvneeshSingh: that's confirms the rewriting axe we've adopted here.
gautierchomel: tricky to determine what the reading system supports vs. what the EPUB has.
Hadrien: there's also confusion because the eBook can claim it works with TTS, but maybe the reading system does not provide the service.
George: Amazon says for example Screen Reader Supported
Hadrien: and some DRMs can block TTS.
wendyreid: There is some necessities on the reading system side to refine information on available functionalities. I'm not sure how to articulate the conditionals depending on the reading system.
Hadrien: that’s make a link with actual discussion in fxl working group about what TTS does exactly.
gpellegrino: RS limitations are addressed in the principle, but not for every information. See example : https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/#visual-adjustments
Georges: reading system TTS is evaluated in epubtest.org. People who don't know needs to look at RS evaluations done where we test with different assistive technologies (AT) to help people chose the best reading system for them
rickj: there's probably a need to tie books claims and RS capabilities in the future. But not now.
CharlesL: maybe we can reuse the principles and techniques in epubtest.org to make sure functionalities informs are tested.
Topic 2. Review of samples of localization JSON files:
AvneeshSingh: https://github.com/w3c/publ-a11y/tree/64350f9c27a8f309317cbfbd3a4dbf7e5e17927d/UX-Guide-Metadata/draft/localizations
gautierchomel: localization, clear process for translation of the words that are used in the principals / techniques. … same vocabulary used. We will accept multiple versions say for French. French Canadian, vs. French Belgium. Even in the same geography could have a different localization. we won't rate it either. … interesting to have mechanism to keep track of localization and help with translations. provide a tool to help we get one translation pair. … we agreed to use JSON file. duplicated for each localization. … nested pair values, canonical mix of JSON was the most up to date proposal. we have 1st level of metadata … four letter language, language French from France varient from EDRLAB scholar , academic, etc. audience we are serving, how it was obtained. … tried to reuse the keys used in principal document for each key we have two nested keys compact / descriptive. … example we have is in the principals. would like to get feedback on who would use this kind of file. would it be difficult to use etc. … once we agree on the file we can see if we can use it in Transifex for translation for example.
rickj: Strongly support Mixed format others have weakness. … using numbering system can be limiting. … variant vs. language codes. FR-FR , FR-CA etc.
gautierchomel: variant multiple FR-FR (EDRLAB vs some other organization) maybe the author.? … maybe we don't need the variant key,
rickj: variant in the language code yes.
wendyreid: We may want to align with EPUB. looking over C-Mixed gives the best option. … can we stop using Read Aloud, should be more specific. … complimentary audio / text does that mean Sync media or transcript?
AvneeshSingh: This falls on side of principals document we should address this not in the JSON file. this is just the structure. Please open an issue for that.
George: Matt and I wrote a document about these confusing things, we published last year. we attempted to clarify. will find the link.
can we get a link to the clarifying document George mentioned added to the transcript?
AvneeshSingh: We already had a lot of discussion / debate for the Principals document for many months. we can revisit there with a GitHub issue.
gautierchomel: IETF Language tags.
Hadrien: serialization easier to not use JSON for that. we might want to consider YAML which is less likely to break things
AvneeshSingh: we are discussing this with Ivan to have a repo for this. … we would like to use a tool instead of folks editing the JSON directly. … we need to test TransFX for accessibility.
Hadrien: all of them support different file formats but JSON is usually more difficult
gpellegrino: once we have a localization if we use TransFX only use the UI there for localization it will be only the developers who need to use the JSON files.
gautierchomel: Maybe I am over engineering this with using JSON.
AvneeshSingh: we need to start collecting the terms and we need to figure out what is the best option to capture this and then utilize with what tool we will use and what file format would be best.
AvneeshSingh: lets figure this out in the editors call
rickj: we love JSON so don't give up on it too quickly. :)
gautierchomel: you would use a JSON file directly?
rickj: Yes, and we would produce that as part of our translations as well.
AvneeshSingh: We are at the end of the call. Let us continue discussion in 2 weeks from now, in next meeting.
Raw original minutes:
https://www.w3.org/2024/02/08-pcg-a11y-minutes.html
Present: AvneeshSingh, Bill_Kasdorf, CharlesL, ChrisOliverOttawa, gautierchomel, George, gpellegrino, Naomi, rickj_, Romain
Regrets: Chris Saynor
Chair: AvneeshSingh
Scribe: gautier.chomel
Meeting minutes
Topic 1. Further editorial changes done in the principles document of User experience guide for accessibility metadata. (For information purpose
AvneeshSingh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated
AvneeshSingh: reviews and comments on the principle document are welcome. Editors are still doing some fine tuning here, no major changes.
Topic 2. Editors are making progress on techniques.:
AvneeshSingh: https://github.com/w3c/publ-a11y/pull/223
AvneeshSingh: we have a proposal for the techniques documents.
gpellegrino: before the end of year break we agreed to use a pseudo code approach. I made some proposals in the ONIX techniques document on how to present the instructions. Among editors we agreed with a syntax (IF, AND etc.). We are searching for the best HTML markup to provide a nice reading experience in visual and non-visual reading. We are near to a good result but still need some tweaks. As soon as we are ready we'll make a proposal.
George: we are also trying to maintain a common approach for both ONIX and Schema techniques.
Topic 3. Discussion on localization workflow.
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/190
AvneeshSingh: we need to discuss how to make it practically work, where is the folder for localization, what is the workflow for volunteers. Gautier, would you like to brief the discussion happening on the issue.
gautierchomel: three question : where do we store the localizations, in which format and which workflow (pull request or help from a service like Transifex or git localizations)?
George: English is the main source. We should have it in the main repo. Then PR can be proposed by anyone with a GitHub account. We should not judge the quality of the proposed vocabulary.
rickj_: we first need the canonical set.
romain: in epubcheck we use transifex service, it provides an UI to people translating. All strings are stored in properties files java specific format which is synchronized by transifex. The service also synchronized back to GitHub. Different similar services exists and most may have free service for open source projects. There are details to check but it's very simple for the user.
Romain: https://help.transifex.com/en/collections/3519116-file-formats
romain: some tools may propose custom language codes allowing for variants of one language
George: may we imagine having different localizations of the same language for different segments of users?
rickj_: may happen. It is possible that we use little different sentences for higher ed, than others.
rickj_: we can start by creating the structure (the canonical file)
rickj_: FWIW - we do everything in UTF-8 no BOM
CharlesL1: using a tool will also help to avoid encoding errors and language codes classification.
Romain: as for Weblate, here the supported input formats: https://docs.weblate.org/en/latest/formats.html
AvneeshSingh: gautier will share a JSON file with the editors and in the issue tracker..
AvneeshSingh: let the discussion follow in the same issue w3c/publ-a11y#190
Raw original minutes:
https://www.w3.org/2024/01/11-pcg-a11y-minutes.html
Present: AvneeshSingh, CharlesL1, ChrisOliverOttawa, gautier, George, gpellegrino, Hadrien, mgarrish, Naomi, miiak, JonasLillqvist.
Chair: AvneeshSingh
Scribe: CharlesL1
Meeting minutes
Topic: Further editorial changes done in the principles document of User experience guide for accessibility metadata. (For information purpose)
AvneeshSingh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated
AvneeshSingh: Editorial changes to principles Doc. Charles added some editorial improvements in a PR. … for any other improvements please open an issue.
Chris: there is a closed group, ask permission to post a draft.
AvneeshSingh: Comments are welcome.
Topic: Approach for techniques documents and localization:
AvneeshSingh: Here are two relevant links
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/217
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/190
AvneeshSingh: , for techniques we discussed using pseudo code vs XSLT in previous call, and group members pointed out that Pseudo code is more understandable, and we should try to make it understandable for people who are not developers. In editor’s call we discussed the feedback further and decided that we should make it even simpler by using plain English statements for explaining the decision tree. Gregorio has given a pull request for ONIX techniques to provide an example. If we have time and resources we will also provide XSLT for developers to use, but primary deliverable will be these plain English statements for techniques.
Avneesh: Let us talk about Localization process. The localization should be from English reference sentences. In version 1.0 of principles document we provided terms, but now we are providing descriptive sentences for explaining accessibility metadata in the publications. The retailers can use these descriptive sentences. the localization should use these descriptive text in English as reference. For example, there should be English to French, English to Italian localization, instead of going from French to Italian. We should have a separate repository for localizations, where we should also highlight the individual, company, organization, or group which has done the localization, so end users can make decision for how trustworthy the localization is.… , v1 well defined English terms and the localization of these terms. But in this version we are providing descriptive text, which is non-exhaustive list of sentences. Coming up with a huge list with all permutations is not feasible. So, the reference sentences in English will be a non-exhaustive list. We would like to extract this list of descriptive sentences while we work on the techniques, because these sentences are likely to change while working on techniques. This is the plan.
George: we want to identify in this repo template who has submitted the work, description of how it was developed, governmental group, or whatever process, the language that is used and expect each entry would get an ID to be referenced. so when they produce their Italian version and LIA worked say with 10 people, and it is in Italian, and the ID of that Entry in English Version produced. … , always has an ID that can be referenced.
Charles: +1
JonasLillqvist: +1
Miiak: +1
Topic: We are converging on the approach for Search and filtering:
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/196#issuecomment-1843300918
AvneeshSingh: It looks like we are settling on the last post of Rick Johnson on this issue. It is saying that we should have two sets, one is minimum set which everyone should display, and other is extended metadata, which is adapted according to your users.
Minimum set includes supports visual adjustments, non visual reading and show publications with any metadata reported. the extended set includes support for MathML, extended descriptions etc. Let us go step wise. First proposal is if all of us are fine with presenting two sets, minimum set and the extended set of metadata? Please do +1, 0 or -1 for this proposal.
JonasLillqvist: +1
Miiak: +1
AvneeshSingh: approved.
RESOLUTION: Using the Minimum / Extended Metadata for Filtering
Avneesh: Next step is to discuss if we are OK with the three pieces proposed in the minimum set?
gautierchomel: Minimum set - 3 metadata (discovery of any accessibility metadata provided. one search option any title with accessibility metadata. main information ways to read: search titles non-visual reading, and visual adjustment. Any title with a11y metadata, nonvisual and visual adjustments are the 3 main metadata set.
AvneeshSingh: What about Conformance? Should it be added if your local legislation need it?
gautierchomel: this is currently in the extended set. this can become mandatory depending on the regional requirements.
George: is conformance going to be required for EAA?
gautierchomel: from French authorities, currently just require the accessibility metadata
George: any implementer can always display / filter on any of the metadata.
gautierchomel: there can be 50/60 items to search by, but if we just elements about minimizing other facets. we want to have a min set that should be implemented everywhere.
Charles: wasn't there a requirement for 3rd party certification for conformance?
gautierchomel: not to my knowledge, the legalization can always change so it’s not up to us.
AvneeshSingh: there is CMARK for the products, and EPUBs are in the services.
… , maybe Gregorio can send out an email to us if this is not the case.
JonasLillqvist: discovery of all titles with accessibility metadata, what about accessibility Feature "unknown" or "none"
AvneeshSingh: We can add a note to this.
Hadrien: for this filtering capability if we push for more a11y metadata there is a lot of volume with TOC, page navigation. There may be 1/2 of this in a very large number of books, does this defeat the goal of this? is it useful if we know if a publication has a TOC and that is all?
AvneeshSingh: Good question, any thoughts?
George: I know Internet Archive only has 1 entry with a TOC
Hadrien: OVER 90% have a TOC. … , TOC 92% actual numbers, Print Pagination 15% … , lot of books with just those two and nothing else.
George: when a11y metadata is unknown that there is only TOC for accessibility that a11y metadata is absent?
gautierchomel: not a lot of folks will document unknown or none. but through inferences we could get minimum set, but should that be displayed? We don't have the ability to say documented vs. inferred. could get it from ONIX few publishers are not capable, could extract the metadata from the OPF or inferred by looking inside the book.
AvneeshSingh: Inferred is out of scope at this stage.
gautierchomel: we must address this in the future. this document is not only for Europe. … , EAA this will increase these facets as accessibility metadata will be required in 1-3 years this will grow due to the new legislation. It will be great when we need to revisit this since all the books in Europe have this metadata.
Hadrien: aside from what the filter returns what is missing is expression of the need. … , ex. I need publication which supports non-visual reading or enlarge the font size. … , the need for any accessibility at all -expression of need, maybe smaller subset.
JonasLillqvist: I think Hadrien has a point. but only the min set of 3 that are displayed I am not sure it will be useful to find / filter on the first facet.
Charles: used in conjunction with other filters to reduce the list size.
gautierchomel: I understand this better now.
gautierchomel: , stick with 2 minimum facets and add a note about accessibility metadata include it with which context may be interesting.
AvneeshSingh: proposed: minimum set of accessibility metadata should include Titles that support non visual reading and Titles that support visual adjustments.
JonasLillqvist: +1
Hadrien: +1
Charles_l1: +1
Miiak: +1
+1 George
AvneeshSingh: resolved
gautierchomel: Discovery of a title where very view titles have any accessibility metadata to find them. we hope that vast majority with accessibility metadata it won't be very useful. … , could result in a false positive. … , complex to achieve you can't say any ONIX 196 code is present then we assume we have accessibility metadata. I am pretty sure achieving a facet to view 40 + metadata properties.
AvneeshSingh: we will bring this to the editors call.
Hadrien: In our case, AccessMode Sufficient for auditory the entire text is pre-recorded audio. this is interesting there is a very large group of users where this would be very useful. … , having entire publication as audio.
AvneeshSingh: the decision here is not carved in stone, we can revisit any of this in the future. I like your point it is very important. … , prerecorded is a very strong use-case is this for all parts of the world or not is the question. Let us focus on approach for Extended set of metadata. We should provide 4-5 examples for different kinds of user segments. … , we can do this in an incremental way. A continuous process.
AvneeshSingh: Any objections?
RESOLVED
Topic: Any other business.
George: Acknowledgments are incomplete. I suggest multiple people should be added. Folks can send your names for Acknowledgments.
AvneeshSingh: Please send to kerscher@montana.com
AvneeshSingh: Thanks everyone and Happy Holidays. We will meet again on January 11, 2024.
Raw original minutes:
https://www.w3.org/2023/12/14-pcg-a11y-minutes.html
Present: AvneeshSingh, CharlesL, ChrisOliverOttawa, cristina, gautierchomel, George, jgriggs_prh, Madeleine, mgarrish , Miiak , JonasLillqvist
Regrets: Rick, Gregorio.
Chair: AvneeshSingh
Scribe: CharlesL
Meeting minutes:
Topic: Further improvements in principles document:
AvneeshSingh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated
Avneesh: we have been making many edits to the document with implementing feedback from multiple people. Any other improvements?
George: will add the word "claims to meet" instead of just "meets xyz" in the Conformance section.
Charles: agrees.
Charles: I have multiple editorial issues, but was thinking MathML should be called out in the Charts Graphs and Formula section.
Avneesh: if you have more feedback please include it in GitHub.
Topic: What approach should we use for techniques documents?
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/217
Avneesh: we need to start working on the techniques document as the Principals document is getting close to being finalized.
… there are two ways: XLST provides advantage that implementers can just use it, or the other approach is to use Pseudo code. It makes it more readable and you can create multiple implementations in Java, XLST, java script etc. How should we proceed?
George: do you know if Gregorio made the pseudo code from the Xslt file himself.
JonasLillqvist: I comment on the issue in favor of pseudo code. programming language agnostic.
gautierchomel: Last version of the techniques I don't see any pseudo code. I am not sure. We need to written form of what we want. This is what we should first offer. … Then we can include examples, but we need to make sure we don't get overloaded. I think 2 voted for pseudo code. … I still like XLST, we could have an implementation section. … , showing what triggers in the example one XLST doing everything in the document. could be beneficial.
Madeleine: No code just examples of the metadata itself. We may need to check multiple sources of metadata so implementation examples ie. schema.org and ONIX, and could be MARC. We will need multiple XLST for each of these implementations. … pseudo code is more readable and what others have said but coders would love the XLST which they can just then grab and use. can this group maintain this and make sure it is bug free. Do we have the capacity to do this? If we have to prioritize one I would go with pseudo code. … XSLT should be a stretch goal.
Avneesh: maintenance can be a big challenge. To summarize, Pseudo code is first preference but XSLT could be an advantage and could maybe use XSLT to create the pseudo code via ChatGPT potentially.
Topic: Approach for supporting localization of descriptive sentences which retailers and distributors will display:
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/190
George: We have many strings that explain the accessibility of the document. That are generated from the metadata. We are trying to get it right in English. The meaning of these different strings, we need more than a translation. We must have it localized that the meaning is equivalent not just the translation. We would like to make these translations available to everyone to reduce duplication, but we don't want to say its an official translation but just a suggestion, and others may want to contribute to localization. May end up with multiple for any given language. So we need to get the strings defined in English and then set up a mechanism to gather other language conversions.
Avneesh: table of multiple translations is not practical. We were thinking of a repository and set up a control system maintained by volunteers. Community groups can review and approve / modify these before it gets included in the repository.
George: Rick has offered to translate into 37 different languages.
gautierchomel: 2 aspects: maintaining a list, not sure if we can be the judge of one over another. … , asking for volunteer providing the translation, is it from one organization or done via a project like we have done in France. … , have a table of translations we can see if it has been done from a company vs. an organization, so we don't make judgements. … , first guide asking for feedback, which we have done in France, organizing workshops getting the feedback. What we got a true understanding from all the actors. … , we now have an implementation in France,
Madeleine: if we are approving translations wouldn't we need an expert in that language? So Gautier's approach will be more scalable by providing who did the translation.
George: I agree. W3C has a formal process for WG's this is a Community Group, we don't have the resources / language expertise. Identifying the organization they did it and process they used will help people to decide if they want to use the translations. … , Rick might say this was done by VitalSource and had localization experts do the translation. English should be used and go from that to another language always. that would be the recommended process.
Miiak: I agree, as a speaker of a European language … , some of these languages may be hard to find. Complicated to get organization for smaller languages. … , I have seen many translations into my language have multiple errors. … , We can help with the Finnish language
Avneesh: Thanks, we will finalize the process in the next Editors call.
Topic: Please comment on issue on search and filtering. We will discuss it thoroughly in our December call:
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/196
Avneesh: this is important, having guidance on filtering and discovery. Filters are dependent on the audience. We are trying to find out some least common denominators, and can expand for specific audiences. … , looking pretty complex, we can discuss today if anyone has some ideas. … , otherwise we can defer to Dec 14th.
George: Would a library / retailer provide a prepopulated type of search? Or if I did a google search of accessible books in EPUB format what would I get. Unclear how this will work. But love the idea of finding accessible books.
gautierchomel: you can search for a word, but list of books. searching for "moby" then get a list of facets, then you can filter on "EPUB" to reduce the list then can further reduce with other facets like supports non-visual reading.
Avneesh: is the filtering criteria is prepopulated.
gautierchomel: the facets are pre-populated. … , you may have 100 facets, but this could be unwieldly.
q§
cristina: What do you mean about filtering. I am not sure how easy this will be. Advance search could be very different depending on the bookstore etc. … , will there be some kind of search for all math books that are accessible?
Avneesh: Yes that is what we are trying to solve.
Gautierchomel: w3c/publ-a11y#196
Madeleine: I think we need to say something about filtering, and encourage sites to do filtering, every site does filter differently … , current thought minimum filtering that is needed the most then expand. not all sites will have an accessible math filter. Some facets might not appear depending on the site and their audience. … , I am in favor of a minimum filtering set then expand. … , helpful to know what the minimum is is needed would be helpful.
AvneeshSingh: Madeleine, it would be great to have your comments on minimum set.
Madeleine: Sure I will think about that.
George: if you can add a comment, this would be great.
Avneesh: Any other business?
Avneesh: Thanks everyone. Next call is on Dec 14th, last call of the year.
Original raw minutes:
https://www.w3.org/2023/11/30-pcg-a11y-minutes.html
Present: AvneeshSingh, CharlesL, gautier, George, jgriggs, Madeleine, Naomi, rickj, Chris_EDI, Bill_Kasdorf, Gregorio.
Chair: AvneeshSingh
Scribe: CharlesL, Gautier
Meeting minutes
Topic: Further update to principles document of User experience guide for accessibility metadata:
AvneeshSingh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated
AvneeshSingh: a lot of work has been done on editing.
Gregorio: gave and update on the overview.
Rickj: I would like to give a pull request for general overview section. in education marketspace, it may not be the student but the instructor will choose the book.
Madeleine: +1
AvneeshSingh: Yes, we should provide a general statement highlighting that accessibility metadata is not only important for print disabled users, but also the decision makers like professors. Looking forward to the pull request. Some more comments from me:
AccessibilitySummary paragraph in general overview talks about the difference between EPUB Accessibility 1.0 vs. 1.1. Should we move this down to the AccessibilitySummary section instead of the overview? Going into details for one specific metadata in overview looks like one metadata is hijacking the introduction.
Gregorio: ingesting metadata from machine readable is important and the accessibilitySummary isn't as it was intended like before.
AvneeshSingh: We can add a short statement for change in EPUB Accessibility 1.1 in general overview, and provide the specific detail in AccessibilitySummary heading in Key Accessibility Information.
Next comment is for the note in the Key information: when there is no a11y metadata provided, it should be stated. This is a blanket statement applicable on all accessibility metadata groups, but in last call we decided 3 main groups where retailers should explicitly state that no information is provided, if these accessibility metadata is not provided by the publisher. Should we just mention this in these specific sections.
Rickj: +1
Gregorio: +1 to remove the general note and add this info to each specific section.
George: I am worried when no metadata is provided. … I agree modify the blanket statement.
AvneeshSingh: we can update the statement.
rickj: for no a11y provided, are we looking for a standardized statement?
Rickj: what we say if no metadata is provided: The publisher of this title has not provided any details on the accessibility features that may be included. You should contact them for more information.
AvneeshSingh: the implementors should inform users that the publisher hasn't provided that metadata, we are not asking to use standard sentences for it.
rickj: 3.2 pre-recorded audio.
AvneeshSingh: lets hold that for now
Gregorio: it is required in the EAA metadata must be displayed. the 3 key information must be provided, and each one that no a11y metadata provided. visual Adjustments: No information is provided, Conformance, : no Information is provided. etc. not just one statement.
Madeleine: I am on board with modifying it, I think it’s still important to have some general statement like "If no metadata is provided in those 3 key sections." but also point it out in each section.
rickj: What should we say: 1. no metadata is provided, but we know that they meet the minimum requirements because we will reject that book should we infer this . we may get metadata from the book or ONIX or out-of-band if there is conflict between them or just present all of it to the user and let them decide.
AvneeshSingh: lets open an issue in regard to your second point where there is conflict between multiple metadata sources.
Bill_Kasdorf_: if a book is in your system, the book has accessible navigation. What about have a blanket statement for your system, that Navigation is provided as a requirement.
rickj: here is what publisher claims, and this is what our reading system claims.
AvneeshSingh: this document only discusses what is in the publication, and if that metadata is not provided, you can use the information we give you, but you can adjust this with saying that the publisher hasn't claimed this but we have enough information that xyz should be accessible, or something to that effect.
Madeleine: +1 to Avneesh
AvneeshSingh: implementation details can be handled by the implementors and we can adjust our statements with future versions.
Naomi: Hazards you can tell no audio/video is not in the book. the reading system / not from the publisher.
George: Internet archive has 1 entry in the nav doc, I wouldn't call that Navigation provided, that’s just the minimum. how to tell real navigation. we haven't emphasized. We do plan on having standardized statements but yet to be done, there will be strings which can be translated.
Gregorio: inferred metadata is possible, so we should open an issue to better discuss this. maybe a Note in our document.
rickj: re translation, if we can finalize those phrases by early Jan, we translate into 37 languages and can provide it back to you. We will take the phrases and translate them.
rickj: Pre-recorded Audio, RS with Read-Aloud, is there a place for this here. is available to the users
Madeleine: that is the Reading System vs. the book. not the features of the Reading System.
George: a Distributor that has that function in their Reading system could add that metadata to the a11y metadata?
Madeleine: supports non-visual reading, in addition, reading tool will support synchronized reading.
Gregorio, non-visual reading, is where that would go. We don't have metadata for text to speech.
Rickj: +1 to those answers
AvneeshSingh: Read Aloud, the accessModeSufficient = "textual" is what we need here. Available to Screen Readers, Braille and Text to Speech Read aloud.
Madeleine: the pre-recorded audio doesn't say pre-recorded vs. synthesized speech.
George: same as human narrated. human vs. pre-recorded.
Madeleine: last paragraph should say pre-recorded has less errors.
George: will we distinguish between TTS and Human Narrated. we will remove the statement about errors.
George: I have seen human narrated with pronunciation errors.
Chris_EDI: ONIX file human / synchronized TTS is permitted,
George: Conformance Section - first to be written, it differs from the other section as a result. Added that certifiedBy is always present, as well as the certifier's credentials. impossible to figure out 3rd party vs. self-certified. so these two items users can figure out who certified it and any credentials they may have.
rickj: I think it’s a great rewrite.
George: Should this section follow the same model as the other sections where you start out with a descriptive statement example vs. a compact statement example. … descriptive, WCAG 2.1 AA level, compact statement would be "meets minimum accessibility standards." … this would allow the implementor to choose if they want the descriptive vs. the compact. now certifier and credentials would be the same no difference between compact vs. descriptive.
Madeleine: I am concerned about the compact statement regarding timeliness
George: that would be still available in the detailed conformance information. Compact statement will require this additional information.
rickj: where are you pulling the date when the certification takes place
Charles: this is a new "refines" the certifiedBy metadata
Rickj: found the date specifics at https://www.w3.org/TR/epub-a11y-11/#sec-evaluation-date
George: detailed conformance information, we can add the compact with no description statements but each of these recommend a section detailed conformance information should be there. leave it up to the implementors. additional details. have the date, and link to the certifiers report if present.
Gregorio: could be a solution, we can decide the naming.
George: statement "detailed conformance Information" 3.7.2 in the spec. we could do compact statement, meet accepted conformance, certifier, credential, and in the detailed section could have the additional conformance details have that other information like the real conformance statement, certifier report / date certified etc. can go there.
George: I will do a PR and have the editors review it.
George: Action to add issue about conflicts of metadata, and inferring a11y metadata, and an issue about adding localization statements. Rick will do a PR the General overview of instructors in education.
rickj: In each of the a11y section we have the descriptive / compact, the links will how come to these conclusions, what is the timing on techniques?
AvneeshSingh: We are now quite settled on key accessibility information of principles document. The next step is to work on techniques.
Gregorio: I agree, and with Chris from Editor will help with the ONIX part, I think we are near to start.
Chris_EDI: Happy to help with the ONIX part and to look at the mapping. We are looking at a feedback loop when there are inconsistencies of metadata. this is a project we are looking at.
Madeleine: Speaking of the crosswalk, I found one more thing, and then we can get that republished. then we should ask Chris to ensure we haven't missed anything.
Madeleine: w3c/a11y-discov-vocab#96
Chris_EDI: Yes, I did a mapping, and look at the comments we can look at it together
Charles: Yes please check and update this issue, I will make the changes to the table then all can review once complete.
Topic: Any other business:
AvneeshSingh: Next call, we can't do Nov. 9th due to DAISY meetings. We will look into meeting end of Nov. … work async for now drive via GitHub. … Nov 30th would be the next meeting I will send out the invite.
Gregorio: can the editors meet next Monday and continue regularly.
AvneeshSingh: I will send out the invite for editors.
Action Items:
- Rick to provide pull request for general overview section, for indicating that decision makers are also audience of this document.
- George: Open issue for conflict resolution between different metadata values coming from different metadata formats.
- George : Open issue for inferring accessibility information through algorithms instead of using accessibility metadata.
- George: Open issue for terms for localization.
Raw original minutes:
https://www.w3.org/2023/10/26-pcg-a11y-minutes.html
Present: AvneeshSingh, Bill_Kasdorf, CharlesL, ChrisOliverOttawa_, gautier, George, gpellegrino, jgriggs, mgarrish, Naomi, JonasLillqvist
Chair: AvneeshSingh
Scribe: CharlesL, gpellegrino
Meeting minutes
Topic: principles document of User experience guide for accessibility metadata is restructured:
AvneeshSingh: first agenda item: the restructuring piece … we started this work on the document on the "Key information" section … now that this section is pretty stable, we moved to organize the rest of the document
AvneeshSingh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated
AvneeshSingh: in this new version we're removing the prioritization of metadata from general overview section, since it's up to the retailer to decide what to display first … the general information and introduction is the old one, the "key information" section was renamed "key accessibility information" … me moved "Discovering accessible content" after key information
Bill_Kasdorf: This is looking great!
AvneeshSingh: then we have "Localization" and "Implementations". In implementation we'll list different implementations (VitalSource and Fondazione LIA are ready, maybe also someone from France)
George: what about the importance of different key information’s?
AvneeshSingh: We should leave defining the order of key information to implementers
CharlesL: maybe we can use a bullet list, so we don't define an order, but just listing
AvneeshSingh: any feedback?
Bill_Kasdorf: we may explicit that there may be different orders for information based on different use cases … it's difficult to make comments on order because you highlight something and "hide" something else
AvneeshSingh: if there is no objection, then let's move on!
Topic: What to display in case of absence of metadata · Issue #184:
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/184
CharlesL: when publisher omit something in the metadata, it doesn't mean it doesn't exist … for example hazards … or like alt-text may mean that we don't have or these are not provided … or conformance
Bill_Kasdorf: I like James suggestion: say "Not reported
AvneeshSingh: during editors call we identified three metadata groups that should be displayed even if metadata is missing: Supports nonvisual reading, Visual adjustments, Conformance … we would like to have feedback from the group
Naomi: I think we had discussion on this … doing a lot of remediation semi-automatically it is difficult to say something that requires human check … to the absence of metadata should be clarified, because in some cases some feature may be present, but not listed in metadata
CharlesL: I would use Accessibility Summary for telling this
JonasLillqvist: I would ask about Visual Adjustments: what is the metadata behind it?
Gautier: Visual adjustments is displayTransformability yes.
gpellegrino: displayTransformability, if we have this, this means the content can change to user preferences, ONIX latest there is way to express this with a code in ONIX (I can't recall right now).
JonasLillqvist: displayTransformability can be difficult to understand.
JonasLillqvist: yes, sometimes displayTransformability is used to divide reflowable from fixed layout
Naomi: This is the a11y-discov-vocab ticket I was referring to: w3c/a11y-discov-vocab#74
Bill: how broadly are you considering displayTransformability?
gpellegrino: There are different levels, we check against WCAG for reflow, enlarging text, we check that. There are some publishers who put this in al reflow EPUBs. 95% reflowable EPUBs can adjust font size etc.
Bill: publishers may just automatically choose displayTransformability. since the Reading Systems can do this.
gpellegrino: could have a reflowable EPUB but could be still problematic.
CharlesL: we didn't update the techniques document, there will be updated links to tell the metadata behind this key information … in our program we check that metadata reflects the content … to be sure that is not used in not correct manner
George: we should make sure that is the textual content that will be transformed
JonasLillqvist: I just looked at the DAISY Knowledge Base, to check what are their requirements for displaytrasformability: not image of text, proportionate units of measures … I think the "images of text" is too strong as requirement
CharlesL: It's true that infographics or images of tables are difficult to manage in live text, so we require to have an alt-text and an extended description … I think that with these mitigations you can claim that displaytrasformability is true
mgarrish: I think this is a long discussion, I posted a link to a PR trying to work on this … not sure if alt-text can be a mitigation … we need further discussion
AvneeshSingh: If we have an agreement on how to evaluate displayTransformability … then we should emphasize this metadata by conveying that no metadata was provided, when displayTransformability metadata is absent. ok let's update the guidance
AvneeshSingh: do you want other metadata group to be in the "display even with no metadata" group?
CharlesL: I think navigation may also be important … especially for textbooks
gautier: I think it is about the audience, if I'm in a scholar context Navigation is important … in fiction this is less important … same in academic: pagelist is important … but I also know that a lot of books do have TOC … so maybe we can recommend to display something about navigation even if no metadata is present
Naomi: Same as Gauthier, but with the example about "Math and Charts"
AvneeshSingh: I think "Conformance" is really important, the other information is more contextual
AvneeshSingh: so we agree to have three information to display always (telling that are missing, if no metadata is present): "Supports nonvisual reading", "Visual adjustments", "Conformance"
Topic: Any other business:
George: the issue about certification, we had feedback about "self-certified" … so I updated the section according to this, I think this simplify the conformance section … Instead of giving judgement if a publication is self certified or 3rd party certified, we leave to the user to figure it out by checking the names of the certifier and the credentials.
gpellegrino : I would say that at the Frankfurt Book Fair there are two events about metadata and accessibility
Supply Chain Seminar from EditEUR (next Tuesday), and accessibility round table (on Wednesday)Raw
Raw original minutes:
https://www.w3.org/2023/10/12-pcg-a11y-minutes.html
Present: AvneeshSingh, ChrisOliverOttawa, gautier, gpellegrino, Madeleine, mgarrish, Naomi, shadi, GeorgeK,
Chair: AvneeshSingh
Scribe: gautier, gpellegrino
Meeting minutes:
Topic: Feedback for refactoring the principles document of User experience guide for accessibility metadata:
AvneeshSingh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated
avneesh: Good news is that VitalSource and lia Foundation have stepped up to implement the guidance and provide us feedback for evolving the guide further. Let us hear from them.
(epagine too, in France :) example : https://www.epagine.fr/ebook/9782072935459-le-cas-malaussene-ils-m-ont-menti-daniel-pennac/#targetAccess
gpellegrino: we certify and have a catalog. we started with our designer to rethink. (showing screenshot). we started in month of May. The idea of the designer was to present categories in boxes... … each box has heading and icon and explaining of metadata . The guidelines have changed since we started, so we updated the mockup in PowerPoint at this moment. We end up with 9 boxes, one for each key information in the guidelines.
gpellegrino: feedback is that there is a lot of information to display and process. We think about a more concise way. If no information is provided, the box disappear, this visual is the case of all metadata are present. Prerecorded audio box will certainly not appear often... … we might see generally 4 or 5 boxes. Our proposal is changing the order to display the information. (showing another visual with only 6 boxes starting by conformance). We also changed the text for conformance. In reading mode we included prerecorded audio information. A tooltip presents the full information... … we merged in a new Content Detail box Navigation, Charts and (?)... We also propose simplification of some texts... … we added a bullet point for presence of image description to be more explicit (even if already mentioned in reading mode)... … to summarize we suggest: new order, box merging and some rewordings...
AvneeshSingh: there are some metadata that must appear even if they are empty, i.e. conformance. We should go to the groups and mark which ones must be always present.
georgesK: agree, we should clarify that point. Also alt text emphasis looks good to me.
gpellegrino: I agree we should define what to do if no metadata is present.
Madeleine: hazards, very few books have hazards, always displaying no or unknown hazard is a question.
gautier: It's fine for me, most of feedbacks is similar of what we received in France … I would like to highlight that also a French operator is implementing the guidelines and we'll have a feedback soon … we're still waiting for users feedback, but may arrive late for this work
AvneeshSingh: it would be nice to have an example section in the document which shows such implementations.
georgesK: so far we have examples of wording, not of real life implementation. So we might create a new section pointing to implementation samples.
gpellegrino: since we finalized this mockup on PowerPoint we are working on a static html sample.
AvneeshSingh: we have an action item here. How should we discuss that?
gautier: what about timing problem? I would like to get the feedback from Italy on HTML implementation … same from France … but I know we would like to close the work on this document by the end of this year
georgesK: rick also mentioned he anticipates feedback from students and teachers filtering and searching for files. He was trying to figure out how to do that. He provided me some feedback on conformance section.
AvneeshSingh: let discuss the conformance. We should just say this is certified by and let user understand if it is third party or inhouse.
gautier: for me this is related to the missing part of what is a "certification" … I don't think we need a complex spec … only some guidelines on what we intended by certification … I see that a lot of certifiers will appear right before the European Accessibility Act implementation
AvneeshSingh: good point. it should be a separate document. Here, what can we do to specify the type of certification (inhouse or tier). My opinion is that it is complex to address from our place, should it be left to the market. Let's create a github issue for that.
AvneeshSingh: back to identifying always visible groups of metadata, I suggest we open a github issue.
georgeK: the conformance section has a different structure with an extra heading level. I wonder if it is for being more complex section and it's ok or should I find the way to flatten the structure?
AvneeshSingh: I think it's ok as the section is more complex. We can discuss in the editor's call or open an issue.
AvneeshSingh: ok, we have action items for opening GitHub issues. Gregorio to propose which metadata group should be present even if there is no information provided, Gautier to propose text to highlight that AltText is provided for images and George to propose how self certification and 3rd party certification is presented (ideally we should not say if something is self certified, user should determine it)
Topic: Any other business:
georgeK: rick mentioned that we should change the introduction, even if quick and dirty so the first implementers can figure out better.
AvneeshSingh: Ok, one more action item for editor's call.
Raw original minutes:
https://www.w3.org/2023/09/28-pcg-a11y-minutes.html
Present: AvneeshSingh, CharlesL, Chris_ED_, gautier, gpellegrino, jamesY, GeorgeK., Madeleine, Naomi_, Tzviya, Ted Van Der
Chair: AvneeshSingh
Scribe: gautier, gpellegrino
Meeting minutes:
Topic: Feedback for refactoring the principles document of User experience guide for accessibility metadata.:
AvneeshSingh: we hope to receive more feedback on the rewriting of the display guide.
https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated
Ted Van Der Togt: I have a couple of things from KB (library of the Netherlands. I feel it's too much about the info book page, the accessibility journey starts before, Is there a possibility to add guidance about filters and facets? The other think is pure audiobook, I would prefer see them well separated from eBooks’. Also I would like a MARC technic document if some people from the library world could help.
Ted Van Der Togt: I work as a researcher for the KB. We have to do a lot about library services. Some people have met me before as I've been working at Dedicon.
GeorgeK.: We have had people who are working on MARC join us on this call.
AvneeshSingh: yes it's in our goals to have techniques for MARC. But the MARC crosswalk is not finalized yet. It is in review. We intend to add techniques document for MARC.
gpellegrino: the filtering part is very important, but it's still not that simple to establish how to determine a facet. It's difficult to just say it's accessible or not, that's why we stopped there. If you have proposals we will add, them because yes it's strategic.
gautier: the comment from Ted on audio I think is pertinent … first section was only about audio … we extended it with audio-synchronized … but I think it makes sense to move "pure-audio" in the general information … (right now we have a placeholder in the document)
AvneeshSingh: yes, we'll work on the general information section
AvneeshSingh: In next revision of EPUB Accessibility we will be addressing the EAA requirement of exemptions. Please see the following PR https://github.com/w3c/epub-specs/pull/2571
gpellegrino: for the EAA (European accessibility act), they are exemptions (micro enterprise, dis-appropriate burden, substantial alteration).
GeorgeK.> Will pure audio books be exempt because of fundamental alteration?
gpellegrino: it's important for publishers to be able to indicate they are not accessible because of legal exemptions. ONIX started to add dedicated codes, the EPUB accessibility metadata had to propose a way. This is the case described in this issue.
Ted Van Der: even if a publisher is exempted, as a library we want to tell the user about accessibility, a simple book could be accessible event if the publisher is exempted. We want to make sure we can tell as much as possible, even in case of exemption. Concerned that making it too easy to claim exemption may lead to less information.
jamesY: I understood that the accessibility has to be reevaluated each 5 years.
gpellegrino: the federation of European publisher's (FEP) also want this metadata for statistics. This information make sense in that way too. the FEP also have a task force about determining exemption limits and understand how they fit publishing business.
AvneeshSingh: looking at James comment, we should open an issue to get more information about it.
gautier: for how the EAA is written it asks every publisher to the best it can to make accessible publications … for what Ted told, there are some tools able to infer accessibility metadata (like Readium go toolkit) … for sure we have to push publishers to do the best they can
GeorgeK.: A publisher may have an exception, but they should not be exempt from inserting the accessibility metadata.
gautier: we see a lot of eBooks’ in France that are quite good, but have no metadata on accessibility … so first step is to remediate metadata
GeorgeK.: we could have a fully accessible metadata + exemption metadata on the same book.
GeorgeK.: accessmodesufficient auditory should be the trigger for audiobooks.
Naomi_: small publishers, it's not only about lack of resources to make accessible books, it's also lack of resources to learn about it. there's a knowledge problem has an important part.
Avneesh: Good discussion. Let us move to the next issue:
Have 3rd Party Certification on Main Accessibility Page #181: https://github.com/w3c/publ-a11y/issues/181
CharlesL: we've been helping publishers make accessible books thru GCA certification. The information of certification should be up in the information section.
gpellegrino: position of LIA is we agree, at least in Italy users trust our work. We think it's important in the front space.
jamesY: I agree as a publisher who has this certification, I want it displayed immediately.
gpellegrino: the choice of displaying stays up to the distributor.
gautier: There are countries where there would not be a 3rd party certification. Publishers would be doing it themselves. If we want to put it in main space, then we should think about companion document to explain what certification is. As there are only two private players on the field today.
Avneesh: Let us have this discussion in the editors’ call, and figure out the text that adds 3rd party certification on the main space and also addresses Gautier’s concerns.
Topic: Any other business.:
AvneeshSingh: next call 28th of September (because TPAC in the meanwhile).
Raw original minutes:
https://www.w3.org/2023/08/24-pcg-a11y-minutes.html
Present: AvneeshSingh, Bill_Kasdorf, CharlesL, Chris, gautier, George, gpellegrino, jamesY, kersc, mgarrish, Naomi, wendyreid
Chair: AvneeshSingh
Scribe: CharlesL
Topic 1. Proposal for refactoring the principles document of User experience guide for accessibility metadata:
AvneeshSingh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated
AvneeshSingh: Overview - editors finished their edits and Matt cleaned up and harmonized everything. The recent changes include:
… Two new sections 4.1 Supports NonVisual reading.
… 4.2 Pre-recorded audio
… simplification 4.7 Conformance
… improvements to 4.6 Hazards
… then added 4.8 Accessibility Summary.
gautier: support nonvisual reading,
… Indicates whether all content required for comprehension can be consumed in text and therefore is fully available to assistive technologies and reading system text-to-speech functionality.
This field answers whether nonvisual reading is possible, not possible, or unknown.
Digital publications with essential content included in non-textual form (such as graphs, tables or equations presented as images, videos, etc.) must include textual alternatives to ensure that users reading with other senses than sight (mainly auditory and tactile) have access to the same information as visual readers. These textual alternatives can include extended descriptions, transcripts, captions, etc. depending on the nature of
the nonvisual content.
… examples:
… The examples are provided as lists of possible descriptive and compact explanations for flexibility of adoption.
George: Matt harmonized the language. In conformance I have single statements on each aspect then I have a paragraph style where things are concatenated. We should be consistent between compact / descriptive.
AvneeshSingh: This seems to be editorial changes which we can address in an editor’s call.
gautier: new section added between computer generated vs. human pre-recorded audio.
… 4.2 Pre-recorded audio
… Indicates the presence of pre-recorded audio and specifies if this audio is standalone (an audiobook), accompanies text (embedded audio and video clips), or represents an alternative to the text (synchronized text-audio playback).
Audiobooks created for mainstream use provide important access for many users with disabilities even though they are not accessible to all. As they grow in popularity, audiobooks may provide more accessibility options in the future.
Some publications provide audio (including video) in addition to text. In this case, it is important that the user gets informed as they may not be able to access all contents of the book.
Some publications provide pre-recorded audio with text synchronization. They are known for providing rich accessibility as pre-recorded audio normally has fewer pronunciation errors than computer-generated speech. Users with hearing impairments still can access the full content of these books. … https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated#example-descriptive-explanations-0: Descriptive explanations
• Audiobook with no text alternative.
• Contents available as complementary audio and text.
• All the content is available as pre-recorded audio synchronized with text. … https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated#example-compact-explanations-0: Compact explanations
• Audio only.
• Complementary audio and text.
• Synchronized audio and text.
gpellegrino: added 4.6 Hazards
… Identifies any potential hazards (e.g., flashing elements, background sounds, and motion simulation) that could afflict physiologically sensitive users.
Unlike other accessibility properties, the presence of hazards can be expressed either positively or negatively. This is because users search for content that is safe for them as well as want to know when content is potentially dangerous to them.
This group should always be displayed. Indicate that no metadata is provided if that is the case. … https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated#example-descriptive-explanations-4: Descriptive explanations
… https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated#example-compact-explanations-3: Compact explanations
Naomi: auto identification, of huge # of titles. assets without audio its easy. For titles with audio there is no "Unknown" is there
… how do you adjust specific flashing vs. unknown audio sound hazards etc.
Charles we do have NoFlashingHazard and NoMotionSimulationHazard and not including sound hazard should be the same as "unknown" for sound.
AvneeshSingh: Should we add a specific example for Naomi's issue here on whether something has a sound hazard or not.
Naomi: We don't include a lot of multimedia. but we may need to have something to listen to everything. which is time consuming and costly. … the spec doesn't give guidance on this at all. for an unknown state.
George: Could a processor go through and determine if there is a loud sound.
Charles: I think it’s possible to pre-scan content for hazards with AI for publishers.
Matt: we don't have a standard for audio hazards too big of an unknown.
AvneeshSingh: Yes thats true EPUB 1.1 no definite way to define. This guide is to interpret the metadata. Little bit of guidance.
Charles: the accessibilitySummary could augment this "Where this SoundHazard occurs".
Matt: This metadata is very vague. maybe something for the editors to dig into.
gpellegrino: 4.8 Accessibility summary
… Free text. … Provides a description of the accessibility that complements, but does not duplicate, the other discoverability metadata.
It is a free-form field that allows authors to describe additional information to the accessible properties of the resource.
Due to its nature, no specific processing of the content is required; it is sufficient to extract the text from the metadata and display it to end users. … https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated#example-an-example-accessibility-summary: An example accessibility summary
Charles: editor note making the examples titles consistent not just "Compact Example" for all the various flavors.
George: 4.7 Conformance
… Conformance info was too complicated. A/AA WCAG EPUB etc. make a real simple statement. … EPUB accessibility 1.0 or 1.1 either conforms to the recommended AA, or it conforms to the specification leave out "At the Recommended Level".
gpellegrino: Identifies whether the digital publication meets internationally recognized conformance requirements for accessibility.
Conformance metadata often uses terminology that most people will not understand, and therefore https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated#conf-statements should be provided when EPUB accessibility and WCAG levels are identified.
If a publication identifies that there are accessibility problems, the statement should indicate that there are known accessibility limitations. If the publication does not include a conformance claim, the statement should indicate that conformance could not be determined.
In many cases, people will want to know more about the conformance and certification of the publication. The detailed conformance and certification information should be included within the "https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated#additional-accessibility-information."
George: Tricky thing. with EAA there are exceptions if there is a small company / undue burden, ONIX will get fields for this. If the publisher is not bound the accessibility requirements what this note covers.
gpellegrino: 4.7.1 Conformance statements … The following list explains the meaning of each recommended conformance statement.
This publication meets accepted accessibility standards.
The publication contains a conformance claim that it meets WCAG 2 Level AA, but no evaluator information is provided.
This publication meets minimum accessibility standards.
The publication contains a conformance claim that it meets WCAG 2 Level A, but no evaluator information is provided. … see https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated#conf-statements for the entire list
gpellegrino: do you all agree with "meets accepted accessibility standards.", "is certified to meet accepted accessibility standards"
Matt: does this get to self-certified the difference between.
George: with you are 3rd party certified then this would be "certified"
Matt: certified one is when there is 3rd party. We need to update those definitions then.
George: I have inserted examples an expandable HTML details then it lists in a compact form each feature of conformance. then I concatenated this all into a paragraph which is more readable then in the AAE as the final example.
https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated#example-additional-accessibility-information-shown-as-individual-statements: Additional Accessibility Information shown as individual statements
Bill_Kasdorf: +1 looks useful
https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated#example-unknown-accessibility-conformance: Unknown accessibility conformance
Naomi: We have examples for meets and self-certified, and micro publishers. This file should be one for no info
Mgarrish: CharlesL: how are we going to get the information about a micro-publisher? is that in the summary? seems like it should be in a note because we won't have that information
Charles: where does this information come from about micro publishers not needed about a11y
George: this is now in the new ONIX fields.
gpellegrino: Numbers are correct, this is request for the Federation of European publishers since there may be fines. So it will be important to tell this info to the end user.
Naomi: In addition to pub size, what about book types Children's pictures books.
gpellegrino: we checked this to the exemption, micro enterprise, and others like comics, children's those publications should be done at State of the art not part of the codes.
Charles: we need to make clear that this information can only be displayed if you also have the ONIX feed. could be included in the a11y summary.
Mgarrish: w3c/epub-specs#2569
AvneeshSingh: ONIX it is already there, in EPUB metadata we will see if we can add it.
AvneeshSingh: https://github.com/w3c/publ-a11y/issues
Topic 2. We will meet again on August 24, 2023:
AvneeshSingh: Editors will have at least one call to improve it before out next meeting.
w3c/publ-a11y#175 https://github.com/w3c/publ-a11y/issues/175
Matt: folks to have a look at Publications that don't meet accessibility requirements #2569, and Define EU conformance exemption metadata #175
AvneeshSingh: please provide more feedback. … thanks all.
Raw original minutes:
https://www.w3.org/2023/07/13-pcg-a11y-minutes.html
Present: AvneeshSingh, CharlesL, gautier, GeorgeK, gpellegrino, Hadrien, laurab, Makoto, mgarrish, Naomi, Chris, Tzviya
Chair: AvneeshSingh
Scribe: CharlesL
Topic: Proposal for refactoring the principles document of User experience guide for accessibility metadata:
Gautier: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated
AvneeshSingh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/?updated
AvneeshSingh: 4 sections the editors have worked on. … Visual Adjustments
gautier: As Nav section, quick definition, and some examples. … Visual adjustments one key info vs. Nav with multiple. … 4.2 Visual Adjustments
A Yes/No/Unknown answer to the question "Can a user change the aspect of textual contents".
Indicates if the appearance of the text and the page layout can be modified according to the possibilities offered by the reading system.
Readers with visual impairment or cognitive disabilities rely on the ability to change color of background and texts, font family and font size as well as spaces between letters, words, sentences or paragraphs.
The reflowable information alone is not sufficient to make sure that modifications operated will not result on text overlaying or unreadable colors. … See the 4.2.1 Examples
gpellegrino: this information, we don't use only the positive information … what would be there if one cannot change the appearance of the text. … text on visual and we don't have displayTransformability. … we can say the User can not change the display of the content.
Naomi: if displayTransformabiltiy is present then we can use the first example. We do save text as images, and if the lack of metadata would imply a fixed layout and close to the print version.
George: you aren't putting in displayTransformability in your EPUBs?
Naomi: No because there are text overlayed as an image but a manuscript or poem we would put in the image. Highly designed titles does happen. so we don't use that accessibilityFeature.
gautier: I agree DisplayTransformability is for all reflowable files because parts may not be. … many books will get an unknown value. which is not good for communication / selling books
Hadrien: did a presentation where extracted numbers for Spanish markets 160K EPUB files only 200 of them had DisplayTransformability. I have partial data for other markets. … we are seeing DisplayTransformability is used that much. We see that this is missing. … this is tricky. default situation if there is nothing its unknown. FXL or PDF we would assume that No DisplayTransformability would be implied. … this one is hard to infer.
Charles: Add an AccessibilitySummary if there are images with text but keep DisplayTransformability
gpellegrino: if most of the main content can be transformed then include that metadata and make a note in the summary.
George: I agree as long as the image has proper alt text this is fine.
Avneesh: Principals document there were no negative comments. Most of the comments are for interpretation and if the metadata is common or not.
Charles: I think there are too many examples?
gpellegrino: At least Yes/No and Unknown. we can discuss in editors call
AvneeshSingh: Charts, Diagrams and Formulas
gpellegrino: this wasn't present in excel file, this info was in big group of book features. We needed to subdivide it into smaller set of features. … important info of Charts, Diagrams, and Formulas in STEM. … 4.4 Charts, Diagrams and Formulas
This group of metadata is used to indicate to end users the presence of formulas and complex graphs, charts and diagrams within the title and whether or not these are usable in accessible format: for example, whether formulas are navigable with assistive technologies, or whether extended descriptions are available for complex images.
This group should be displayed only if the metadata indicates the presence of formulas or charts and graphs within the title, otherwise it can be hidden. … see 4.4.1 Examples
… I can express these schema.org values, but same information in ONIX … metadata accessMode ChartsOnVisual, etc. MathML or describe Math, longDescriptions can create this output from that info.
George: It is important to point out that these can be determined depending on the metadata present same for other groups. important to point out in principals that it may require more than 1:1 mapping and it’s a combination
gpellegrino: we have two positive values describedMath and MathML can be used with Formulas, but if those are present only. Charts and Graphs can only be provided if Charts/DiagramsONVisual but longDescriptions must also be present
AvneeshSingh: Conformance
George: 4.7 Conformance
The conformance group provides the assertions made concerning the accessibility of the publication. The language should be simple and report if accessibility recommendations are being met or if the publication is below suggested recommendations. At a minimum, the specification which it conforms to and the party doing the certification must be provided. It is also possible to determine if the certification is done by a third party. If the publisher and the certifier property are different, then this indicates the certification was done by a third party. The credentials of the certifying party and the date of the evaluation will be of interest and should be provided. If there is a link to a report of the evaluation, that can also be provided.
Conformance Statement
Identifies the accessibility specification and the conformance level to which the publication assertions are made. When the publication conforms to more than one specification, additional conformance statements may be provided.
Certifier's name
This provides information about the organization providing the certification review or process for certification. Having third party certification is of high interest and should be provided. Third party certification can be determined by comparing the name of the publisher and name of the certifier. If the values are different, then third party certifications are true. This can be provided as a parenthetical expression, i.e., inside pa
Certifier's Credentials
If the certifier has a badge or a credential, then the text is provided. If there is a link to their credential, then this can be provided as a link.
Certification date
If the date of the certifiers evaluation is provided, then this would be of interest. This is normally associated with the certifier.
Certifier's Report
If a link to a report is provided, this may be of interest.
see 4.7.1 Examples
George: some countries may have A as the standard but others at AA, but the 1.1 specifies AA. … we talked about not being so technical to understand what WCAG is.
… Example 1: • This publication meets accessibility recommendations and reports (EPUB Accessibility 1.1 and Web Accessibility Content Guidelines (WCAG) 2.1 Level AA.)
… Example 2: • This publication falls below the accessibility recommendations and reports (EPUB Accessibility 1.1 and Web Accessibility Content Guidelines (WCAG) 2.1 Level A.)
Next example is a combination of all this information in a paragraph form.
George: I think this paragraph can but generated automatically depending on the metadata provided.
Charles: the date of the certification is a new concept using a new metadata / refines property.
AvneeshSingh: If it is not there in current version of EPUB accessibility 1.1 then we can remove it and add back when we have it in EPUB Accessibility.
gpellegrino: instead of falls below we should make this a more positive spin.
George: I used below but suggested this. how to inform the user but its at a single WCAG-A not AA
gpellegrino: WCAG itself states A is the minimum. that would be easy if A was our minimum. but AA meets the recommended conformance level.
gautier: minimum is a good idea as WCAG states this as well.
George: are we going in the right direction?
Hadrien: I think its a bit much. we have implemented the previous guidelines and the conformance section is confusing for people. This publication is "Fully Accessible" (loaded term)
Tzviya: +1 to Hadrien
Hadrien: book retailer will be difficult to display this information. Things will get lost. … too much of a massive info dump.
Charles: that’s where GCA / LIA certification would be is needed if present.
tzviya: What happens for those not 3rd party certified? we need something more simplified use-case … something more meaningful for other publishers. I am trying to figure this out for Wiley. … lets think about how this works in the real world, assume folks don't have GCA or small publishers. easy to use.
Chris: from the Library point of view have no expertise in this area at all. We could just rely on this metadata if it meets the standard.
Hadrien: When we tested this metadata we had users who didn't even know what EPUB is or what a certification program / WCAG is. could be a blocker / opportunity. … users don't know that an EPUB with Fixed layout you can't modify the text in the book. … we need to use this line of thinking with those who don't have this expertise. I think we can make this an opportunity.
gautier: standard accessibility conformance reached. might be something
AvneeshSingh: We can take this up in the editors call to flesh this out.
George: meets the recommendation or minimum recommendation. … seems like what that short paragraph needs to be clear and says it either meets or doesn't meet the specification, but what about self-certification vs. 3rd party.
tzviya: I like example 17, but I would simplify it more "This publication meets the accessibility recommendations" if there is a report link to that.
AvneeshSingh: we can create a GitHub issue.
Hadrien: boils down to trust. international organizations different countries will do things a little differently. may not be a one size fits all cross borders.
AvneeshSingh: these are examples and can update it as those countries see fit.
George: appropriate publisher provided certification, multiple things are provided. ie. "Certification information is provided" which can then be viewed in greater detail upon request.
Hadrien: that info is useful when you don't trust. … if you recognize some certification program thats when it becomes more useful. could vary from publisher to publisher etc.
tzviya: in the world of a11y a certification report has been established. university / libraries may require some certification. populating this metadata before it becomes a requirement. is smart
George: is self-certification meeting recommended standard and if that is self-certified would you say that. only put "Certified" if its 3rd party certified. … agreement on meeting requirements, but do we put in "certify" if its 3rd party vs. self-certified (gets to the trust thing).
tzviya: I will think certify if it comes from a 3rd party, vs. something internal
Topic: Schedule for July and August?
AvneeshSingh: Should we have one more call in July? 13th of July then take a break for a month, and then meet in 4th week of August.
Several participants: yes
AvneeshSingh: next call July 13th.
AvneeshSingh: George you can add a github issue with the examples asking for more feedback.
Raw original minutes:
https://www.w3.org/2023/06/22-pcg-a11y-minutes.html
Present: AvneeshSingh, CharlesL, ChrisOliverOttawa, gautier, gpellegrino, Hadrien, jamesY, jeffrey_griggs, Madeleine, Naomi, GeorgeK
Chair: AvneeshSingh
Scribe: gautier
Topic: Proposal from editors' for refactoring the principles document of User experience guide for accessibility metadata:
gpellegrino: This is the link with respec. We worked the Navigation Section.
AvneeshSingh: we are categorizing the metadata’s to make them manageable then explaining and proposing example’s of display. We have to deal with a lot of information. Writing in a user friendly and implementable way is challenging.
gpellegrino: we've worked collectively, Avneesh, Charles, I, George and Gautier... the wording may change but we are proposing a structure to apply to each key information’s. We started with Navigation. First paragraph is a definition, second one is refining the definition (was rationale before). Then examples provided as extended (multiple sentences) or compacted (one sentence)... … each sentence of the extended example is related to one metadata. We are interested on your feedback before writing other key information’s.
CharlesL: The example Landmark is a great one of what is missing in metadata.
AvneeshSingh: Indeed landmark should be reported in Accessibility Summary because there is no machine readable metadata in which this information can be provided.
GeorgeK: we have description that can be used to understand how to translate / localize wordings. Two different implementation examples because diversity of realities.
AvneeshSingh: we want to know from the group if we are on the good way.
Naomi: I like the structure, it's pretty understandable. I'm just not sure of the Implementation subtitle related to ONIX / Schema.org techniques. It should probably be "technical set up to trigger examples" but to be simplified to be a heading.
GeorgeK: the concatenated sentence is nice but also the most complicated to elaborate. We have to think of absences and partial presences. Would it be: there's no navigation tool provided? Do we say no Index?
gpellegrino: implementation could be called techniques as it refers to the names of the documents as announced in the introduction... … on concatenated phrase I think we can find an easy way.
Naomi: +1
Madeleine: implementation I was thinking about Metadata techniques.
AvneeshSingh: we can reserve one more week to give a chance to implementers who are not on this call to give a feedback.
GeorgeK: when we think about localization, the items to localize are examples.
gpellegrino: localization is expected for all examples, but localization implementers may use some flexibility in translating terms to their language. Here. I prefer separated examples so we can refer to each sentence separately even in separated sentences example. To check how ReSpec can handle a good presentation.
Hadrien: just pointing out during implementation we struggled with finding the metadata. We have a better view of market provided and file provided metadata’s, we see a massive impact on this discussion. Will be presented in Madrid readmagine, at least about the work done on Spanish market. To be done for other markets, we hope to have it for September. This will give us an idea of what in the display guide is actually possible to show.
Naomi: we are about a week away from using onix to epub mapping table produced by this group. Any file newly produced will have ONIX accessibility. Thank to everyone who did this mapping work, it has been crucial for us.
AvneeshSing: it's good to see real life implementation. Thank you very much!
Chris: we are updating ONIX code lists and we plan to send the proposal to that group. It's going to be a big update. If there is agreement of national groups it should be published in July. No deprecation. It's about adding details and precisions. It does not affects only list 196 but also 81 and others.
AvneeshSing: very nice information’s, see you in 2 weeks.
Raw original minutes:
https://www.w3.org/2023/05/25-pcg-a11y-minutes.html
Present: AvneeshSingh, CharlesL, Chris, gautier, GeorgeK, gpellegrino, Hadrien, jeffrey_griggs, JF, Madeleine, mgarrish, wendyreid.
Chair: AvneeshSingh
Scribe: Gautier
Meeting minutes
Topic: Proposal from editors' for refactoring the principles document of User experience guide for accessibility metadata:
https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/
https://docs.google.com/spreadsheets/d/1rUCXkVE0bFeXf0hJvyPkKkIBeBHIGPYUFWKrQqLJHl8/edit?usp=sharing
gpellegrino: (sharing the screen), it's a draft of the document. We mentioned we'll focus on section 4 where we have Metadatas to be displayed. We will create headings for each category mentioned in the spread sheet. For each category group : we will have a definition, a rational, and then examples of user facing terms which are mapped to accessibility metadata. And then a link to implementation. These are only placeholders for now... … in the implementation section there will be link to how to extract information’s. Only one example is written to see if it works. It is "enable reading without sight". The draft will be pushed online after this call... … we changed the wording "screen reader friendly" as non visual reading may be not only thru a screen reader. Currently we focus on the high level structure of the document. Wording will be improved in a second time.
GeorgeK: should we put English wordings identified to facilitate localizations? We want to make sure other languages can set up a translation based on definition.
Hadrien: we struggle while implementing the previous version of this document. We quickly realize not everyone does not know what a screen reader is. This is accessModeSufficient: textual, it addresses also TTS. we had people in schools that made no difference between media overlay and TTS. Telling people what it does is more efficient than trying to define the technology.
Avneesh: This is important, after finalizing the structure we need to work on really user understandable examples.
wendyreid: the user is not thinking about the source, TTS and media overlays are viewed the same, screen reader users know what they need..
JF: interesting discussion because there are many different end users. I see multiple group with different needs. The structure of the document is fine.
Gautier: For me screen reader is not just the reading, but it's also navigation, other features. Screen reader will get different information as well ... structure is quite good, the sub-headings with the definitions as a question seems to be important I wonder if the current definition, as a question, should also have a use case I wonder if we could add definition and use case
wendyreid: definition of TTS, MO, screen reader maybe useful in glossary. This document will also help publisher's understand what they have to inform.
GeorgeK: interesting point, it will help publisher's. In the beginning, we designed it for distribution systems. The scope of this documents is migrating.
CharlesL: primary focus is distributors, but it is useful for publisher's and vendors because it allows them to see what will happen when they add a metadata.
gautier: Agree with Charles, yes the focus is distribution, but clearly the publishers can benefit from how it is displayed.
AvneeshSingh: any objections on following this structure? No? ok, let's resolve it. editor's will go forward and we'll have nice discussions about wording.
Madeleine: +1
Chris: +1
GeorgeK: +1
Gautier: +1
Topic: Next call on May 25:
AvneeshSingh: There are a lot of DAISY and W3C meetings in week 8 to 12 May. So, we will meet again on May 25. The editors’ will work on restructuring meanwhile.
Topic: Any other business:
Chris: briefly, we at Editeur are working on the code list and wording (196 but also other related code lists). not exactly a 1 to 1 mapping with schema but we are looking to a clearer mapping. I will share as soon as I have something sufficient.
AvneeshSingh: Thank you!
Raw original minutes:
https://www.w3.org/2023/04/27-pcg-a11y-minutes.html
Present: AvneeshSingh, CharlesL, GeorgeK, gpellegrino, jamesY_, JF, mgarrish, Bill_Kasdorf, Chris, JonasL
Chair: AvneeshSingh
Scribe: CharlesL
Meeting minutes:
Topic: Approval for publishing of the AccessibilitySummary authoring guide. https://w3c.github.io/publ-a11y/drafts/schema-a11y-summary/index.html
George: For me it's done. Next revision we will make a lot of changes, for now its ready. I implemented everything that was asked for.
AvneeshSingh: In next version we should implement the refactoring of table recommended by Gregorio.
AvneeshSingh: proposed: approve accessibility summary authoring guide for publishing as CG report
Gpellegrino: +1
CharlesL: +1
GeorgeK: +1
JonasL: +1
JF: +1
AvneeshSingh: resolved
Topic: Next steps for revision of User experience guide. We should focus on refactoring section 4.
AvneeshSingh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/draft/principles/
AvneeshSingh: We ultimately need to add this to the Principles document. … we should not try to achieve perfection, and move this over as soon as possible.
AvneeshSingh: https://docs.google.com/spreadsheets/d/1rUCXkVE0bFeXf0hJvyPkKkIBeBHIGPYUFWKrQqLJHl8/edit?usp=sharing
AvneeshSingh: to GitHub.
AvneeshSingh: w3c/publ-a11y#148
ISSUE: merging "Reading Mode: Audio" and "Reading Mode: Non visual"?
AvneeshSingh: We just need to come up with a name but can refine it later if needed.
gpellegrino: One for reading mode audio and one for reading mode visual. … non visual reading mode means using AT … there was a proposal for coming up with a name for each.
AvneeshSingh: issue tracker I proposed an explainer sentence: "enable reading without sight". … we can always change in the future.
gpellegrino: its fine for me. … row 12 to row 15, and row 20-23 … non visual 12-15 then reading mode audio 20-23
12-15: accessModeSufficient = textual
accessibilityFeature = ttsMarkup
accessibilityFeature = readingOrder
accessibilityFeature = alternativeText
20-23: accessModeSufficient = auditory
accessibilityFeature = synchronizedAudioText
accessibilityFeature = highContrastAudio
accessibilityFeature = audioDescription
AvneeshSingh: this is just a placeholder for now.
GeorgeK: Matt & I wrote this modes of reading and can redo to make this in line with this.
AvneeshSingh: resolved.
AvneeshSingh:: w3c/publ-a11y#155
Gpellegrino: w3c/publ-a11y#155
gpellegrino: we missed accessMode, we need to add it.
AvneeshSingh: for completion we should add it to the spreadsheet. Then we can figure out where will it go.
JF: +1 for completion sake
gpellegrino: just identifies that a mode is present.
AvneeshSingh: w3c/publ-a11y#156
AvneeshSingh: Gregorio for this issue, please suggest an idea in github and we can comment.
gpellegrino: ok
… Books features: proposal subgroups for those book features. like what we are doing for Reading mode. … • Structure and Navigation Terms
• Adaptation Terms
• Rendering Control Terms
• Specialized Markup Terms
• Clarity Terms
• Tactile Terms
• none
gpellegrino: we can leave this open for discussion. maybe we can think about it later.
AvneeshSingh: Yes, We should move decisions taken up to now to the User Experience guide and these subgrouping can be done and refined as we move ahead.
Gpellegrino: w3c/publ-a11y#157
gpellegrino: missing metadata - some a11y features and hazards and should add them.
… • accessibilityFeature = pageBreakMarkers (perhaps the pagination source should be included as well?)
• accessibilityHazard = noFlashingHazard
• accessibilityHazard = noMotionSimulationHazard
• accessibilityHazard = noSoundHazard
• accessibilityHazard = unknown
AvneeshSingh: approved, we should add this also for completeness.
AvneeshSingh: We have a huge list of metadata to put in the principles guide. would be good to chunk it up into smaller pieces.
gpellegrino: 1 group at a time?
+1 to avneesh proposal
AvneeshSingh: put in all these new groupings, new descriptions, put only the names of categories and items and then add the descriptions later.
Bill_Kasdorf: always tempting to put in tabular fashion, and not use tables but use lists instead in the guide.
AvneeshSingh: put all categories as headings and list of all metadata and then add the description, managing overload of info will be the tangent.
GeorgeK: principles needed to be updated we also in techniques we will have opportunities of translations like "Screen Reader Friendly" will principles on which docs to read next? Or put a lot of that detail in principles. ie. how will we divide it up?
Charles: maybe have a language option and then can go to the various techniques documents in another language and those terms would be in that language. so if Screen Reader Friendly is not good for another language then that would be defined for that language.
JF: WAI documents Shawn should be coordinated for any translations. maybe invite to one of our calls. Who will do the translations.
Bill_Kasdorf: We could never provide all the translations necessary.
AvneeshSingh: We are not planning to translate, we will create a structure to facilitate that can be translated. Organizations like EDRLab or LIA can translate in their languages. we will discuss this with Shawn. we will have this framework in place.
JF: Agreed include Shawn is well advised here.
GeorgeK: the focus on what we want to translate is the user facing information. to describe the features , access modes etc. we are just translating very short phrases. I don't think we should translate into all languages just the user facing descriptions.
Bill_Kasdorf: +1 to George
gpellegrino: localization of the strings not the actual text of the document.
AvneeshSingh: editors should have a call, put forth a plan and present to this group.
CharlesL: +1
+1 to Avneesh's plan
AvneeshSingh: Agreed.
Topic: Any other business:
AvneeshSingh: I will have a conflict for this time-slot on other W3C commitments. … can we use a doodle poll is that accessible now? is there another version.
GeorgeK: Wendy in chat says its still broken. … Charles and I have a biweekly call, if we could set it up after this at say 15:00 UTC that would work for Charles and I
JF: I am flexible on time.
Bill_Kasdorf: +1
Chris: +1
AvneeshSingh: 15:00 UTC / 11 Boston. anyone conflicts… none ok. resolved
we will have calls at 15 UTC, on same days
JF: conformance statement … want guidance on how to do that we can declare in metadata that a conformance statement exists like URL. … Is there a standardize format. are we using VPAT
GeorgeK: this is regarding a Conformance Report not Conformance Statement ie. conformsTo
JF: everyone is doing whatever they want. … its often the same players. I have been trying to get an answer to if we are looking for new work. what we mean / expect. … I would like to do this at the book level. We are working on a remediation tool and can export a certifier report … if LIA is blazing the trail maybe we should look like they are doing and we like it then that’s one step closer to a standardized report.
gpellegrino: the URL on our server which has a page on our server I can send a link John. Cover, title, with the accessibility features, and just to inform that it is certified by us or not.
AvneeshSingh: can you check Gregorio to LIA is ok to share with this group.
JF: I thought the certifier report was a lot more granular, and has the WCAG + the EPUB specific. we are working towards GCA certification, and must meet all the WCAG.
AvneeshSingh: LIA’s purpose is validation so a reader can validate the claim is correct, but you may be using for providing the details of conformance.
JF: my understanding is different than what LIA's interpretation.
AvneeshSingh: both are correct. … please open an issue then we can work on it through github.
JF: Ok I will open an issue.
AvneeshSingh: I can do that and send the link to the mailing list so we can discuss it there. use it as verification / detailed report … SMART report is an option
Bill: what Gregorio is certifying is an individual book, vs GCA is certifying a publisher/vendor pipeline … VPAT is slightly different again on this date this is the state of a11y at that point in time.
JF: if we have GCA then books are compliant. I know there may not be 100% but GCA has that 80%, EPUB is a collection of web pages we should be able to do a dated VPAT for individual publications. is it hosted on a third party server we can point to it … concerns about pointing to a server. … need more precise I think we need this and maybe even in WCAG 3. lots of all challenges.
AvneeshSingh: I will open the issue then folks can comment … we will have our next meeting at the new time. Raw original minutes:
https://www.w3.org/2023/04/13-pcg-a11y-minutes.html
Present: AvneeshSingh, Bill_Kasdorf, ccarr_, CharlesL, ChrisOliver, gautier, GeorgeK, gpellegrino, Hadrien, jamesY, jamesY_, JF, mgarrish, Hans, Jonas, MiiaK
Regrets: Tzviya
Chair: AvneeshSingh
Scribe: CharlesL, JF
Meeting minutes
AvneeshSingh: Introductions of new members
HansBeerens: introduces himself (welcome!)
Topic: Feedback for Accessibility Summary authoring guidelines:
AvneeshSingh: https://w3c.github.io/publ-a11y/drafts/schema-a11y-summary/index.html
AvneeshSingh: this document has been under review for couple of months, have some feedback from LIA.
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/152
Gpellegrino: reviewed doc, added some comments
Summary name is a bit misleading
perhaps start with an intro of what the purpose is, then "the story" (history) of why this was made optional
idea is this is for other info that cannot be described with existing metadata
[agreement]
GeorgeK: will get to that
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/153
Gpellegrino: suggests that the tables for accessibility summary are good, but --- machine readable data: suggest changing first column with some questions to aid content creator
for example: can you be sure you meet WCAG AA? or "Does the publication include an index?" and then follow on questions
another example: distinction of type of math content (MathML vs LaTeX)
comment: there is some redundancy in current draft
GeorgeK: all of these may have machine-readable metadata, but the idea here is if that data needs enhancing
GeorgeK: if a book has 1 MathML example, then the metadata would confirm that, but we would then be able to qualify that there is only one (or minimal) MathML
Gpellegrino: agree, but what is put in the summary is not what is in the metadata, but in the content
for non-expert implementers, they may see a mapping and get confused?
CharlesL: this is going to be difficult. In GeorgeK's example, if there is only 1 math equation in the book, then fine, but if there are multiple math’s as images, then we need to tease that out further
CharlesL: understands Gregorio's direction, but this means there will be a lot of questions. i.e. "Do you have "limited" math equations?
This will be unwieldly for publishers
another example: does not fully pass WCAG AA - one image is not conformant... then what?
JF: if we introduce questions, we need to qualify those questions (eg: "Limited" = how many?)
Gpellegrino: eg: tables are provided as images, with full text provided in
CharlesL: response to JF - don't want to be defining Limited, but rather some use 1 technique, others use another
Bill_Kasdorf: +1 to Charles--it's not about a number, it's about whether there are inaccessible equations, tables, etc.
GeorgeK: approach was to associate the nuance statements with a specific metadata entry
Gpellegrino: +1 for me
GeorgeK: brainstorming... what if we scrap associating this with other machine readable MD, and instead provide categories of nuanced explanation
we list those as general areas of book structure
and completely revise the table
Bill_Kasdorf: +1
Charles: I like the idea of broad topics, we can have sections on Math, Images, Tables, Language etc. then specific questions in there. … GCA publishers will use this document on how to write a11y summary as soon as its ready.
JF: +1 George's idea a guided tour on how to write this. … focus on problem areas, "have you declared this as metadata" do you want to add more about it. … consistency is important as well. … huge +1 on guided tour on how to write the summary
George: I can get the first part updated quickly the abstract can be updated in the next couple days. then we can look at making changes after that. will take a while and consensus, we could change table head for guided tour approach.
JF: basic template shows those levels and publish that. giving folks a framework early would be helpful … table with 5 rows topic statement would be useful starting point
AvneeshSingh: proposed: finalize current structure and release Accessibility Summary document, and in parallel start work on restructuring
GeorgeK_: +1
JF: +1
+1
+1
<jamesY_> +1
+1
<Bill_Kasdorf> +1
+1
+1
AvneeshSingh: resolved
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/154
gpellegrino: multiple documents… we may want to be part of the techniques or some index.
AvneeshSingh: lets bring this up in the WG maintenance group
Topic: Presentation from Hans Beerens from Dedicon for displaying accessibility metadata:
Hans: Demo on metadata … from Dedicon Netherlands
… Introducing Accessibility Metadata - research user values, introducing and using metadata … Dutch Royal Library … Jun 22 - Mar 23 … mock catalogue made, conducted interviews/ discussions, international developments, workflow … functional catalogue, ebooks audio books, recreational reading EPUB3/2 pdf mp3 daisy wav. displayed all metadata … schema and ONIX. many a11y search filters
… objective is to evaluate a11y metadata, 1 blind, 2 low vision, 2 dyslexic, 2 no reading impairments … given tasks, with participants speaking their though process. at home using their own AT … Findings: most claimed no value metadata was useful. most irrelevant. Not inclined to use filters to find books. … most didn't understand most metadata but did acknowledge some would be useful. … either a book is a11y or not. … some assumed that books would be 100 accessible. assumed you can change contrast. a11y features are for VI users only, some had inaccessible experiences in past ie. no TOC etc. … Readability for dyslexic users clarification. … introducing a11y metadata into the supply chain. … recommendations: introduce human readable metadata … machine readable metadata should also have equal focus to introduce this to new users to support the learning curve the adoption and prevent mistakes when adding metadata. … make a11y metadata accessible … explanation of concepts and importance. helpdesk / kb or workshops. … different reading purposes, recreation, school study, etc. … different levels of complexity simple / mod / complex … different libraries have different audiences and may required different ways to display UI/UX follow international guidelines on display. … showcase mockups samples design options. emphasize business case. … how to present a11y metadata, and update over-time … share knowledge and collaborate
AvneeshSingh: There are so many people with disabilities who have use only specialized libraries, from your research we realize that we need to consider facilitating them in learning the purpose of accessibility metadata in the main stream, why it is important and how to use it.
JF: recommendations slide - provide a human readable summary of the features in the book, the summary shouldn't echo the machine readable data. are we heading in the wrong direction.
Hans: no, we should focus on the Machine Readable data, its not about A11y Summary, people should be able to use and understand the useful a11y metadata to discover accessible books.
JF: so the Machine Readable metadata should be presented in a human readable form?
Gpellegrino: this is what we're working on in the UX guide :)
Hans: people need to understand what this metadata means, and focus on the communication of the metadata and what it implies and allow systems to communicate
Bill_Kasdorf: So this is where our User Experience Guide comes in, correct?
JF: so you "library tool" it would fall on at to present in a human readable format.
George: accessModeSufficient = textual translated to "Screen Reader Friendly" but will be translated into another visual indicator or other appropriate language which makes sense for that audience.
Hans: end users need to know what to expect
JF: different tools may export it to the users, but translated the Machine Readable metadata into a Human Readable / understandable way
gpellegrino: we need to find a way in the User Experience Guide to make this mapping.
]AvneeshSingh: will send Hans the invite for the User Guide work, and Hans will attempt when time permits to attend that group.
Bill_Kasdorf: Do have any insights on Educational Reading?
Hans: Recreational reading was chosen due to funding. Scientific reading could have more a11y challenges.
Topic: Discussion on grouping of the relevant accessibility metadata for user experience guide for accessibility metadata:
AvneeshSingh: We are not left with much time today. Please comment on issue #148 on GitHub.
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/148
Topic: Daylight saving time adjustment in terms of UTC from next call:
AvneeshSingh: US will be day light saving time, and will be 1 hour earlier. Meeting on 23rd, same time in the USA, but time might be different in other parts of the world.
GeorgeK: on 23rd should try to get as much done on the Summary. should I try to do both abstract and work on the table header / associated with metadata.
Hadrien having mic issues, and asks: I don't have an invite for the 23rd
AvneeshSingh: In case I am not able to make the 23rd and I will inform the group in advance. I will send out the invite due to DLS time
Original raw minutes:
https://www.w3.org/2023/03/09-pcg-a11y-minutes.html
Present: AvneeshSingh, CharlesL3, ChrisOliverOttawa, gautier, GeorgeK, gpellegrino, Hadrien, tzviya, wendyreid, Jonas, Miiak_, paulgilius,
Chair: AvneeshSingh
Scribe: gautier
Meeting minutes
Topic: Accessibility Summary authoring guidelines. It was in review period: https://w3c.github.io/publ-a11y/drafts/schema-a11y-summary/index.html
gpellegrino: I’ve sent private feedback to George with suggestion, i can try to find it or open issues. On the abstract we could start saying the name is misleading (rewrite the abstract) ; second issue on tables. presenting a11Y feature in first columns does not help understanding. The risk is repeating information already present in machine readable metadata.
gpellegrino: we could convert this table in questions. We think, this document as standalone may not help. It should be linked from some other documents also.
AvneeshSingh: we shall wait for George to discuss issues (as he is main editor of this document)
CharlesL3: thanks for this feedback. I think they are all good ideas.
AvneeshSingh: Gregorio you can put this on the issues tracker. so that it can be discussed with George.
Topic: Discussion on grouping of the relevant accessibility metadata for user experience guide for accessibility metadata:
gpellegrino: we still have 3 issues open. tagged PDF; reading mode audio / non visual ; accessibilityFeature None. There are also 2 new issues raised re-looking at the document I found that there are missing points in the Display Guide: accessMode is not present (only accessModeSufficient) ; book feature group is a long list of confusing terms we may create sub groups.
Gpellegrino: https://docs.google.com/spreadsheets/d/1rUCXkVE0bFeXf0hJvyPkKkIBeBHIGPYUFWKrQqLJHl8/edit#gid=0
Gpellegrino: w3c/publ-a11y#151
AvneeshSingh: tagged pdf is not a norm or conformance, more a feature.
gpellegrino: maybe similar to structural navigation
tzviya: there are few metadata’s related to specifics formats, this is the case of tagged as well a large Print for example.
CharlesL3: large Print could be used for Fixed Layout or PDF
proposed: tagged PDF should be moved to generic metadata
gpellegrino: +1
Jonas: +1
Tzviya: +1
CharlesL3: +1
Paulgilius: +1
Gpellegrino: so we leave it where it is :)
resolved
gpellegrino: w3c/publ-a11y#148
WendyReid: we have to take care of respect content creator here. Is he capable do determine his content can be read non visually?
gpellegrino: the question to solve from user point of view is does this content fits the needs?
wendyreid: content creator can say "we have done nothing to block non visual reading". On retail side I prefer to display what is available. Non visual reading will depend on RS possibilities.
AvneeshSingh: Since this is non-visual reading, Gregorio, I think that the main issue to solve is to have a term to indicate that the content enables reading system and assistive technology to provide non-visual reading experience. We mainly need a good term for it, as reading mode is more of reading system capability. Let us get back to GitHub and settle on a good user oriented term.
Hadrien: screen reader friendly is too technical, we decided to say readable through synthetic voice or text to speech
Gpellegrino: w3c/publ-a11y#150
AvneeshSingh: accessibilityFeature: None ; we need a way to indicate a publication is inaccessible. It's clear in ONIX (196-09), not so clear in schema.org
gpellegrino: in Europe we will need more metadata to indicate why it is not accessible (microenterprise ; burden or other exemptions cases). But it is a separate discussion.
CharlesL3: it's unlikely an EPUB has zero accessibility feature. The interest is to be able to indicate that something is missing clearly, not to say that we just don't know.
gpellegrino: I agree, it's strange to say there is no accessibility feature at all.
AvneeshSingh: so we can't use accessibility feature none to say it is non accessible.
GeorgeK: something else in conformance statement may be needed. You still get basics EPUB accessibility for free.
wendyreid: reflowable will always have display transformability. I agree we will never have no accessibility feature in an EPUB. We don't want to say there is nothing. I don't have the good answer but we need a way to express partial accessibility.
AvneeshSingh: My proposal is move this to feature group from the conformance group and get back to schema CG for exploring metadata for saying that publication is not accessible.
CharlesL: I like the idea of having a way to express partial accessibility (instead of presuming there is no accessibility at all).
Hadrien: it's possible to have an EPUB with no accessibility, reflowable with bad CSS blocks display transformability. There are also fxl with only images. I think one can produce non accessible epub unfortunately. With those epubs we also won't see any accessibility metadata inside.
GeorgeK: the need is something to alert a school that a document don't meet minimum requirements.
gpellegrino: it is a rare case where we express thing in a negative way.
Hadrien: general principles is if anything is not present it is unknown. We need in some context to be able to express negatives (no pagination for school use is an issue). I don't expect publisher's to include this info but a platform selling to schools I need to be able to express that. This missing is an issue.
proposed: move accessibilityFeature=none to book features from conformance
gpellegrino: +1
Miiak:_ +1
Wendyreid: +1
Jonas: +1
CharlesL3: +1
resolved
AvneeshSingh: we'll take up the remaining issues in next call and meanwhile on GitHub.
Raw original minutes:
https://www.w3.org/2023/02/23-pcg-a11y-minutes.html
Present: AvneeshSingh, CharlesL, chiara_de_martin, ChrisOliverOttawa, Christopher_Carr, gpellegrino, Hadrien, jamesY_, JF, Madeleine, wendyreid, Jonas, MiiaK, Naomi
Chair: AvneeshSingh
Scribe: CharlesL
Meeting minutes:
Chris: I am from Editeur, ONIX editor.
Jonas: CELIA new hire
Topic: Discussion on grouping of the relevant accessibility metadata for user experience guide for accessibility metadata:
AvneeshSingh: Gregorio added a number of issues.
gpellegrino: trying to group a11y metadata into a few categories.
AvneeshSingh: Google spread sheet: https://docs.google.com/spreadsheets/d/1rUCXkVE0bFeXf0hJvyPkKkIBeBHIGPYUFWKrQqLJHl8/edit?usp=sharing
gpellegrino: , a11y metadata is a lot more extended outside of a11y itself, so trying to group all the values about 7 categories. some specific values where they should exist. We have GitHub issues for those and naming of these groups. Or combining of groups if agreed.
… , first issue is #145 accessModeSufficient= visual is relevant to EPUBs
w3c/publ-a11y#145: https://github.com/w3c/publ-a11y/issues/145
… , number of comments have discussed this in the GitHub issue. accessModeSufficient of visual could not be accessible in other ways. if only visual.
Madeleine: It is important to differentiate, what metadata should books have vs what is valuable for libraries / bookstores to display in limited space.
gpellegrino: I understand Charles's last comment in the issue for searching. For this having metadata in book is important, it may not be displayed.
JF: +1 to Gregorio
gpellegrino: blind users will filter out all books of not having "textual"
Naomi: problem saying anything that has a lot of pictures is a picture books. could be old terrible books that had all images of text say in a cookbook that is made up of just images.
gpellegrino: looking for grouping say we use this metadata in reading mode. Will this mean a readingMode "visual"? current we have readingMode, textual, audio, and visual adjustment. could we add it to visual adjustments?
Charles: I think visual adjustments makes the most sense.
gpellegrino: I agree
AvneeshSingh: proposed: move AccessModeSufficient=visual to ReadingMode:visual adjustments
Gpellegrino: +1
Madeleine: +1
Wendyreid: +1
MiiaK: +1
JF: +1
AvneeshSingh: resolved
w3c/publ-a11y#146 https://github.com/w3c/publ-a11y/issues/146
gpellegrino: madeleine informed us, HCD means content meets WCAG 1.4.6 … , contrast minimum and enhanced this is highest level AAA contrast used in special publications made for low vision users.
gpellegrino: , since we have this assumption we move this accessibility feature move to Reading Mode Visual, or in the book features where we collect a lot of a11y features
JF: In WCAG there are 3 color contrast issues, text contrast the is non-text contrast for visuals. … , not sure where that fits into this discussion.
Gpellegrino: https://www.w3.org/2021/a11y-discov-vocab/latest/#highContrastDisplay
gpellegrino: this refers to only text contrast and images of text 1.4.6
JF: the WCAG WG they ack a gap. We need to note we have high contrast book without that distinction.
Madeleine: you are right John, but we can't change the definition of the meaning of High Color Contrast metadata in this call.
AvneeshSingh: Yes we can add this point for future additions to metadata to handle this new WCAG criteria that John has discussed. We can delegate it to a11y schema.org values CG.
gpellegrino: maybe the name of the category isn't the best, but an end user content is visually adjustable. is a basic feature of reflowable EPUBs. Is info is relevant to most users in reflow-able epubs and not in fixed layout epubs. Could be content itself to the book feature instead.
Madeleine: +1
Charles: I agree with that. its a book feature not a visual adjustment
AvneeshSingh: proposed: move high contrast metadata to book feature
Wendyreid: +1
Madeleine: +1
jamesY_: +1
MiiaK: +1
AvneeshSingh: resolved
w3c/publ-a11y#147 https://github.com/w3c/publ-a11y/issues/147
gpellegrino: useOfColor thanks to Madeleine two similar metadata which means similar but opposite
From Madeleine's GitHub comment: the ONIX term means "don't worry, there is an alternative to use of color" whereas Schema/W3C has the term "color Dependent" as a part of the AccessMode vocabulary with the definition "Indicates that the resource contains information encoded such that color perception is necessary." If images are accompanied by alternative text, that may remove the barrier. … , where to put this metadata in our groups. currently under visual adjustments, but maybe we should move it to book features. … , this is a WCAG AA requirement.
AvneeshSingh: proposed: use of color metadata under book features
Madeleine: +1
Jonas: +1
MiiaK: +1
Gpellegrino: +1
jamesY_: +1
AvneeshSingh: resolved
w3c/publ-a11y#148 https://github.com/w3c/publ-a11y/issues/148
gpellegrino: "Reading Mode: Audio" and "Reading Mode: Non visual" should we merge them.
AvneeshSingh: Synthetic speech vs. human narrated audio
JF: I would argue against merging them, what about Braille Output. … , tactile reading mode.
gpellegrino: non-visual reading mode jumping from 1 heading to another, the audio is more beginning to end,
AvneeshSingh: maybe its the name that is a problem.
Madeleine: Non-Visual seems like not a lot of users would understand. Audio everyone would understand. we need to make book providers are already making those types of books easier to find.
JF: +1 to Gregorio
gpellegrino: audio may also mean media overlays in EPUB,
JF: could we call it "Reading mode - Pre Recorded"? … , non-tech people know what we are talking about.
AvneeshSingh: Media Overlays?
JF: well those overlays would be pre-recorded right?
gpellegrino: Yes, but could be done with deep learning voices apple / google is pre-recorded is right word. what about a different word for non-visual.
wendyreid: challenges here straying into reading systems. non visual reading via reading system with TTS. … , if a RS has these features could have a audio based reading modality when a reading system offers this even if the EPUB itself didn't provide this. … , auto-generated from AI audio books.
AvneeshSingh: non-visual needs to be replaced then we can decide what fits. … , lets discuss this online in GitHub / a future call.
w3c/publ-a11y#149 https://github.com/w3c/publ-a11y/issues/149
accessibilityFeature = bookmarks
gpellegrino: Madeleine identified - This feature was included in Schema.org for describing reading systems, not books. … , different interpretations of this metadata … , bookmarks to key points as was defined in PDFs … , do we leave it in book features or navigation section, since its in the navigation for PDFs, but since its deprecated in W3C definitions
gpellegrino: if its used in interactive TOC in PDF then this is critical as TOC in EPUBs so important. Since PDF's don't include a11y metadata then I suggest keeping it out of the grouping, we didn't mention this since its deprecated.
AvneeshSingh: proposed: keep bookmarks metadata out of the guide, while providing explanation.
Madeleine: +1
jamesY_: +1
wendyreid: +1
Jonas: +1
MiiaK: +1
Gpellegrino: +1
AvneeshSingh: resolved
w3c/publ-a11y#150 accessibilityFeature = none https://github.com/w3c/publ-a11y/issues/150
gpellegrino: does this makes sense to include? do we group it in conformance section. From Madeleine - This term was added to support the ability to make accessibility Feature mandatory. If a book is not accessible, we might still have hazard or accessMode info available. accessibilityFeature needed to be able to have a value for those cases. … , does it make sense to have in conformance section even though there wouldn't be any conformance statement
AvneeshSingh: Yes we should keep it.
gpellegrino: do we group it in conformance or some other place.
Madeleine: I think conformance is a good spot. people looking a features wouldn't be looking there for none
MiiaK: I was going to say what Madeleine said.
gpellegrino: maybe when there is no conformance and a11y feature of none then we can say that it does not conform, not that we don't know if conformance is missing.
Madeleine: I am comfortable leaving this under Conformance. we could recommend where there a conflicts based on the metadata present if we get to that.
wendyreid: looking at case : person who did the metadata that accessibility features are "unknown" odd book with 0 features could even exist.
Charles: there is a11y feature of "unknown"
gpellegrino: we should mention how to handle conflicting metadata. what happens if we have differences in schema / ONIX section on conflicts.
MiiaK: from EU Act smaller countries will be publishers who don't have to follow these regulations they won't know if they conform or not.
AvneeshSingh: Wendy would it harm keeping this "none" under conformance.
wendyreid: could be confusing "Features = none"
AvneeshSingh: ONIX has a code for inaccessible
Charles: isn't inaccessible for ONIX same as "none" and no conformance statement
wendyreid: I wonder if on schema side there won't be a case with "none" or there is some bigger issue here. … , if anything is missing it become inaccessible.
AvneeshSingh: We should take this issue to GitHub and start from explaining the use case for European accessibility act where a publishers want to declare that publication is not accessible.
Raw original minutes:
https://www.w3.org/2023/02/09-pcg-a11y-minutes.html
Present: AvneeshSingh, CharlesL, chiara_de_martin, gautier, gpellegrino, Hadrien, JF, Madeleine, MURATA_, Naomi, tzviya, wendyreid, jean-benoit, Domenico, Christian
Chair: AvneeshSingh
Scribe: gautier
Meeting minutes:
jean-benoit (leslibraires.ca): here to present the work we do in French Canada with funds from canadian governement. With Domenico and Christian.
DBauer: represent German libraries and German metadata group
Topic: Presentation from leslibraires.ca for their work on displaying accessibility metadata:
AvneeshSingh: background is we published a display guide, and now we are in its revision process. So, we are inviting real book seller who are displaying this metadata to know their experience.
Christian Roy: I'm a consultant working for leslibraires.fr, previously at DeMarque, been in ebook distribution for a while. Domenico will show our mockup, we are not a retailer with access to EPUB files, exclusively working with ONIX files. All of our work has to be mapped to ONIX provided by publisher's. We based our work on current data we find, should change when publisher's give more and better metadata. What Domenico will show is to evo[CUT]
Domenico: thank you for inviting us. I'm not a technician, my specialty is user's experience, my background is on research. I do mockups, and study the use made of them then redo mockups in a multiple iteration process.
Domenico: I work a lot in SEO and know a bit of accessibility but I'm not an expert. I'll show my screen and describe everything, please say if it's unclear.
Domenico: this is the book page, what appears on the first screen, what you immediately see is cover, resume, different versions of a book (paper, EPUB, pdf) and there is one line here saying the EPUB version has 6 of 9 accessibility criteria ; pdf has 0 of 8 accessibility criteria. If you click on one of those mentions you're transported to the bottom of the page where a list indicates "the epub version is compatible with screen reader", etc.
Domenico: The list of criteria is not yet fixed. This list allows you to directly add to basket or choose another version recommended as more accessible or audio version. List items of accessibility functions included are green, missing ones are red and an orange says there's a particular point of attention
Domenico: The pdf list with 0 of 9 criteria ends with "we do not recommend this pdf version for accessibility".
Domenico: we also propose an accessibility page that combines only books with accessibility feature with a set of search filters dedicated (large print, audio, synchronized, navigation, etc.).
Domenico: we did not tested in real situation with blind users but had good feedback from others users.
gpellegrino: it's difficult to be sure something is missing because ONIX only allows to say if the feature exist. If it is not present it does not mean it's missing (example no alt text may be informed because there are no images).
Christian Roy: yes the hard part is interpretation of ONIX. We anticipate we'll have grey icons (meaning we don't know) and hope we'll have more precise metadata with time.
CharlesL: great presentation, icons are great what labels are attached? Watch out for repeated text, and WCAG AAA should be only AA as AAA can conflict for different disability groups. I like the approach.
gautier: maybe we can cross other lists information’s to check if something is missing (the publication has images but not alt text code is represented means image descriptions are missing).
So if I have 81-19 but no 196-16 I have an accessibility problem
Naomi: yes, no mathML does not presume there is Maths in the publication.
Hadrien: working on this we realized that onix is problematic in many ways (access mode and features missing). We started from the crosswalk document and iterated on that and identified missing things. We need to engage a discussion with Editeur to obtain a better mapping from onix to schema.
AvneeshSingh: We have to move forward further harmonization of ONIX and schema.org a11y metadata.
AvneeshSingh: Jean-benoit, Christian, Domenico, would you like to join this group on a regular basis.
Topic: Discussion on grouping of the relevant accessibility metadata for user experience guide for accessibility metadata:
gpellegrino: we created this spreadsheet to prepare rewriting of the display guide. It's clear we have a large amount of information on accessibility, more than bibliographic ones. We have more than 40 information’s, displaying everything to user will not help understanding. Sometimes it's difficult to understand what an information means, even for us experts on accessibility. The idea is to group metadata to be able to display them in a short[CUT]
AvneeshSingh> spread sheet: https://docs.google.com/spreadsheets/d/1rUCXkVE0bFeXf0hJvyPkKkIBeBHIGPYUFWKrQqLJHl8/edit?usp=sharing
gpellegrino: understandable. It's a starting point to be able to propose wordings.
gpellegrino: this work raised questions discussed in the mailing list.
CharlesL: Here is the Schema.org / ONIX Crosswalk https://w3c.github.io/a11y-discov-vocab/crosswalk/
MiiaK: do we understand correctly that accessModeSufficient:visual means a book with images not described
Madeleine: yes accessmodesufficient:visual only means there are lacks of accessibility
Madeleine: if it is the only accessmodesufficient present.
JF: we should say expose or don't expose, we should not let it to developer’s assumptions.
JF: +1 Naomi that was my concern as well
Naomi: we apply "visual" to manga and this type of works, it's clear you can't consume them with access to text only
wendyreid: same point. reflowable with text sure don't necessary need this information but for fixed layout it is important to inform that text access is not sufficient.
Wendyreid: +1 to the display concerns
Adrien: I go the same direction, comics, mangas, bd are access mode visual actually with no alternative. It's important to support it even if it looks difficult to find a way to display it to the users.
Madeleine: big difference is if another accessmodesufficient is present. Make sure the recommendation does not comes too complex. A way is to use visual alone as a flag for accessibility difficulties
gpellegrino: a super edge case is only one alt text is missing, trying to determine accessibility by a missing information may create false positives.
CharlesL: in that case you use visual comma textual. I would not put only visual.
AvneeshSingh: next step is creating issues on the github so we get feedback before we meet again in 2nd week of February.
Raw original minutes:
https://www.w3.org/2023/01/26-pcg-a11y-minutes.html
Present: AvneeshSingh, Bill_Kasdorf, cdm95, CharlesL, chrisoliverottawa, gpellegrino, Hadrien, JamesY, Madeleine, Tzviya, Laurent, MURATA,
Chair: AvneeshSingh
Scribe: CharlesL, gpellegrino
Meeting minutes:
AvneeshSingh: it is the first call of this year. Happy New Year!
Topic: Revision of User experience guide for displaying accessibility metadata:
Principles: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/principles/
AvneeshSingh: the main decision we made is that we should be focused more on how to interpret metadata and display, and less on the order of the metadata. For ordering of information, we will present some examples as inspiration for retailers and libraries. … then we had an editors' call where we decided to remove section 4, we decided to rewrite the rationale of the accessibility summary. … there was also a need to group the metadata in headings, so the structure of the document becomes more readable.
https://github.com/w3c/publ-a11y/pull/142#event-8170450726
AvneeshSingh: George has already updated the rationale of the accessibility Summary.
https://github.com/w3c/publ-a11y/pull/143
AvneeshSingh: Gregorio has reorganized the principles' document.
CharlesL: we're trying to say that the accessibility summary should not be a duplicate of other machine readable metadata, so to use this field for adding information that cannot be expressed with machine readable metadata.
AvneeshSingh: we'll keep this editorial changes by 5 business days, if we don't get negative feedback up to next Thursday, we'll merge it. … We also discuss to group metadata and to move the definition to the group.
gpellegrino: worked with Gautier, list all EPUB metadata and list all the ONIX code, its not a mapping, and list what are the requirements of the EU A11Y Act. … , proposed some grouping of metadata, Reading Mode and suggested some values (visual adjustments, audio, etc.)
Bill_Kasdorf: could you put the link to this Google Sheet in the IRC or chat, please? It's terrific!
gpellegrino: , these are only proposals, lets figure out the groupings, reading mode, navigation, book features (mathML, long desc etc.), certification, compliance … , 7 groups so far, and some metadata may not be specific to a11y , is this a reflowable, DRM, fixed layout etc. Not in the a11y metadata but in the main section list these in UX guidelines display this info in the page about the product price/title etc.
https://docs.google.com/spreadsheets/d/1rUCXkVE0bFeXf0hJvyPkKkIBeBHIGPYUFWKrQqLJHl8/edit#gid=0
<Bill_Kasdorf> you could just provide view permission, not edit. But thanks!
AvneeshSingh: grouping these in the UX guide and more logical structure.
George: guidance on the format, not part of the a11y metadata. I like. category names, audio book, pdf, fixed layout, media overlays and any of these main stream domains (DAISY 3/2 Megavoice could be considered, EBRF eBRF etc.
gpellegrino: currently the google doc is read only
gpellegrino: what is missing is just consensus on the grid then we can move to the document.
laurent_: I agree the grouping is good, when it comes to the UI and order, be careful to mapping to UI order, empty groups having one set of info that is always displayed main info, and display others that contain information so we don't get a lot of empty groups.
gpellegrino: I agree with laurent_, in this spreadsheet I listed all metadata, some metadata will never appear or in few cases. Eg. tactile graphic etc. Some real cases most used metadata real feel of what may be displayed.
Hadrien: At deMark we have a11y feature in two products, approach taken, primary metadata, and secondary. product page and some while browsing, and the others are not displayed you must do something to see it all, and the 3rd items we don't display too complex. … , primary Conforms to WCAG AA, secondary is a11y features/hazards, and 3rd are access modes that are complex or features that are very uncommon.
AvneeshSingh: this is great and we should show this in some examples. … , google spreadsheet - move forward on grouping this on a GitHub issue and come back to this on our next call. could finalized on next call.
AvneeshSingh: we're trying to invite other groups that are working on metadata display.
Topic: Accessibility summary authoring guide is available for review:
https://w3c.github.io/publ-a11y/drafts/schema-a11y-summary/index.html
AvneeshSingh: the summary authoring guide is open for feedback.
CharlesL: I think that we may close the feedback window in one month. … maybe would be useful to have some real world examples.
GeorgeK: if someone wants to add examples, is more than welcome.
CharlesL: do we have a GitHub issue for accessibility summary feedback?
https://github.com/w3c/publ-a11y/issues/105
AvneeshSingh: in the first call of February we can finalize it.
Topic: Any other business:
CharlesL: Pagebreak: the issue was that we have printPageMumbers accessibility feature … when you use it, you have to put the source of the page source using the dc:source metadata … but in some cases we have paginated publications which are not prinnted … so we're adding a new feature called pageMarkes … and another for pageNavigation (you can navigate by pages using the pagelist) … and we're defining a new metadata element for defining the page source for pagination … we're trying to simplify things
CharlesL: we can add values in the accessibility features' list
AvneeshSingh: Just to clarify, this changes are not for EPUB Accessibility version 1.1, we're experimenting for the new version
matt: eventually we can update the techniques
laurent_: I think this feature is not important only for accessibility, but for everyone experience
CharlesL: GCA we'll push this new version to all publishers that are part of the program
AvneeshSingh: good point Laurent. With this we should end this call and continue discussion on GitHub.
Raw original minutes:
https://www.w3.org/2023/01/12-pcg-a11y-minutes.html
Present: AvneeshSingh, Bill_Kasdorf, ChrisOliverOttawa, Gautier, GeorgeK, gpellegrino, JamesY__, JF, Madeleine, Naomi, Tzviya
Chair: AvneeshSingh
Scribe: Gautier
Topic: Further discussion on the feedback for User experience guide for displaying accessibility metadata:
Avneesh: https://github.com/w3c/publ-a11y/issues/136
https://github.com/w3c/publ-a11y/issues/137
https://github.com/w3c/publ-a11y/issues/138
AvneeshSingh: the main issue is 136 and more issues are related: 137, 138 and 139
gpellegrino: we talked about levels, and we hired a designer to make mockups, starting by visual approach was useful to get what place it takes, etc. I can share drafts with you... … on the screen you see 2 product pages, one on desktop and one on a phone screen... … it is to understand how the levels organization could fit in a web page... … in the space we have a logo near the title that claims compliant with EAA... We think this is the more important information... Then we have a list of 6 tabs grouping information’s as accessibility properties, navigation, non textual content, visual adjustments, audio and hazard. This is our second level... Certifier information is third level presented on the right of the page...
Madeleine: it looks good as a first look, and good job. My concern is that there is a lot of energy going into the accessibility summary too. And it looks that we are doing a difficult job of trying to make all kind of users happy with one approach.
JF: iconography is a very high level information. my concern is related to the requirements of the EAA, is it the same as 501 in US? How to render multiple requirements?
JF: we address global market, it's difficult to localize differently. There are multiple conformances possible, how to address that?
Tzviya: it's a good point, but make sure we are not overloading.
Gautier: French publishers says they need more information and reflexion about inferring EAA conformity from EPUB accessibility
Georges: local legislations should be the first priority. Also about use of level we maybe should just prioritize information’s and says this must be displayed and this is supplementary. Just rank all metadata.
JF: +1 George
Gpellegrino: +1 George
James_: i agree too much information will be ignored. we have to simplify. What is important is the user... … for legal aspect, technical standards are probably the best way to express conformity
JF: pointing to technical standards is the goal and legal requirements don't point at standards. Having 2 reporting values is needed (one for each)
Naomi: many books don't pass conformance, a user may buy a book partially passing but corresponding to his needs. And the two levels thing helps with that. If there is nothing at first level, then let seen what's in second level. It address intermediary period
Bill_Kasdorf: +1 to Naomi
James__: +1 to Naomi
Bill_Kasdorf: publisher need is can I sell this book vs user need is can I read this book?
Bill_Kasdorf: even if it's not conformant details may tell me it fits my needs.
James: technical and legal changes every time and may not change in the same direction. How do we maintain that in time?
Tzviya: +1 to JamesY__ maintaining compliance badges is going to be complicated
JF: 508 explicitly point to WCAG2.0, not 2.1 or 2.2. If any future WCAG is not compatible with 2.0 it's regulator problem, not our.
gpellegrino: what we envision here is similar to other European legislation (example is products with CE mark).
AvneeshSingh: there are so many users over the world and so many needs. When we started this document we had two objectives : provide a guidance to interpret and display machine readable information and how to prioritize the information? We should refactor the document and focus mainly on the first goal of guiding retailers in interpreting and displaying the interpretation of machine readable accessibility metadata. For the second goal we should use softer approach, instead of providing detailed guidance, we should provide three or four examples, one may be for European market, and some other for other markets. The retailers can then themselves make a choice which of these approaches suits their market.
Gpellegrino: +1 to Avneesh to how to interpret metadata
Bill_Kasdorf: +1 to Avneesh
GeorgeK: it clearly needs to be revised, and we should also look at the language proposed (screen reader friendly don't work in French ), I wonder if we could have a localization table in our recommendations.
AvneeshSingh: editors of the document will meet to start the writing.
Gautier: I would also like to contribute as editor.
Topic: Next steps for accessibility summary guide:
GeorgeK: i went thru the document and fixed everything. from my perspective it's done. I expect that when refactoring principles and techniques this will trigger more changes needs to the accessibility Summary.
Topic: Should we have meeting on December 22?
All: skip it, meet next year
Avneesh: so next meeting will be on January 12, 2023.
Raw original minutes: https://www.w3.org/2022/12/08-pcg-a11y-minutes.html
Present: AvneeshSingh, chiaradm, Gautier, gpellegrino, Hadrien, JF, mgarrish, MiiaK
Chair: AvneeshSingh
Scribe: mgarrish
Topic: Further discussion on the feedback for User experience guide for displaying accessibility metadata:
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/136
AvneeshSingh: the issue tracker contains the history - suggested to have metadata at two levels - one is information people need to know and other is more detailed
gpellegrino: two levels is fine but when we try to arrange them we find information is missed - e.g. saying screen reader friendly but not whether helpful for low vision or other users
gpellegrino: https://github.com/w3c/publ-a11y/issues/139
gpellegrino: we tried to group the metadata to give users information in the categories in the issue … general information is general bibliographic information, format, DRM, etc. … second category is about navigation - toc, page list, reading order, etc. … some of these can be calculated by the conformance statement - by meeting WCAG … third category is whether text content is available for non-text content … can you change the color contrast, fonts, etc. - important for dyslexic readers … fourth level is audio like media overlays … then there is accessibility conformance and all the other metadata
Gautier: we need to consider that there are two types of online service that will use this information - special access libraries and also more general bookshelves - there is already a lot of information in bookshelves so can't have too much more … need option if you don't have enough space to display a lot of metadata - you need to display the level 1 metadata in this case … have to let platforms know what is the minimum expected when they can't display everything
AvneeshSingh: yes, need to consider if people with go through a long list
Hadrien: in our case we have implemented the accessibility metadata in aldiko and in portals - our approach has been to use a single section to group the metadata together - grouping in subsections likely won't help with readability - we've selected a subset of information that we think are the most important … for everything else, we group them in a separate element for people who are interested in going beyond - same for certification information - important to know WCAG info but not who checked the book, etc. … balancing act between making enough information available without making it unreadable and unhelpful for readers
gpellegrino: agree that we need to identify what is the most important information - by grouping by categories we get the same result but it is more concise - only nine total for grouping into short sentences to describe functionality
AvneeshSingh: your proposal needs elaborating to also propose what goes into each level
JF: I'm concerned this is about how to present the data rather than mandating what information has to be available - some users may want info one way and others another, they have their own preferences - in WCAG we could not tell the browsers what they have to do, and concern we're just telling user agents what to do - level 1 and 2 map to metadata that must be present … our job is to provide the information and their job is to present it however they need - we should only focus on what metadata must be specified
AvneeshSingh: this is the publishing cg so it is not exclusively EPUB 3 context – EPUB defines the requirements and recommendations - we are providing suggestions on how to transform the metadata in the publications into easy to understand information for users
JF: there is a suggestion for presenting icons - excellent best practice, but are we saying they must do this
AvneeshSingh: no, this is only a guideline document for retailers - they are not clear what to do with the information they find -One of the distributor, for example, started by showing the raw metadata
JF: some of these recommendations will be useful for some users but not for all - if the goal is only to provide guidance then we should show examples - there may be more than one way of rendering this information
AvneeshSingh: yes, there could be multiple suggestions depending on the expected users. We also expect that Charles will be a liaison with the personalization TF
JF: not really the focus of that group - helping users with pictograms - are we saying that we want a standardized set of icons? - many ways of rendering controls that allows them to retain the same information - e.g. users know a triangle is a start button … presentation is going to be a schematic choice - what we propose may not work with branding of vendors … I understand the need and desire but we are constrained in what we can mandate people do
AvneeshSingh: these are only meant as suggestions - vendors do not have to follow it exactly … when we discuss this, the retailers are saying that these are important guidelines that they need
AvneeshSingh: at level one we need to know format, DRM, reflowable or FXL
gpellegrino: for this metadata since they are not only accessibility perhaps they should not be in the accessibility section but elsewhere in the metadata
Gautier: yes
Hadrien: +1
AvneeshSingh: one issue from Charles is that he wants the certification information, not just the conformance statement – he also wants certifier name, badges, etc.
gpellegrino: my personal view, not LIA, is that it is a tricky thing about who certified
Gautier: I agree it is a difficult issue - in France I don't think publishers will go into a certification process so don't want this reported … there is a lot of other information that comes when reporting certifiers - we only use conforms to as it is more easily understood - we will give a link to the report and you can find the certifier information that way
JF: @gpellegrino is pointing out my concern in reality
Gautier: Certifier report works for Thorium but it may not work for others - Kobo will not add a link to external pages for security reasons and don't want users leaving their site … some publishers said they could put the link into the content of the book so that you can reach it from there
AvneeshSingh: seems like this could lead to us having to standardize the reports
JF: +1 to Avneesh... this becomes a slippery slope
Hadrien: geography definitely has an impact - find inconsistencies in how information is expressed - people use the EPUB 3 spec as their accessibility report - makes it hard to have this as top-level information
MiiaK: closed systems are an interesting problem that also affects libraries
AvneeshSingh: adding links sounds like a problem for level 1 - we should report this back to the tracker … having the conformance statement is useful, but keep the details for a lower level
Hadrien: +1
Gautier: +1
AvneeshSingh: need to discuss how to express the conformance
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/138
Gautier: when we've been working on prototypes and in workshops, most of the actors wanted yes or no option - want a way to say we are or are not accessible … people in the publishing industry want conformity with the EAA but don't want complex info - users may get used to understanding the EPUB and WCAG statement but won't initially understand - maybe at the second level there should be a better description that is more human readable … also should say when there is no conformance declared - don't display nothing when this is the case … if there is an exception to the EAA then you need to say that - e.g., because a small publisher
AvneeshSingh: recap: we need to get retailers to state that the conformance is not declared and also have an explainer of what EPUB accessibility and WCAG conformance means
gpellegrino: technical names of the specifications are confusing - difficult to achieve, but we need an explanation of what they mean
AvneeshSingh: will be difficult to explain this briefly
JF: more importantly, is it our responsibility to teach everyone the differences?
AvneeshSingh: how do we find the explanation?
gpellegrino: another approach that we have proposed is to identify if a title is line with the requirements of the EAA - but this is a localized approach for Europe
AvneeshSingh: it is an interesting topic - local areas may have different names of conformance and acts they have to conform to - should we include the local name?
gpellegrino: we don't want another conformance statement but to calculate whether the title is in line with these other acts from the existing statement
JF: concerned we're providing info to the end user, and prioritizing, but localization and translation will affect what to display - when you get down to this kind of custom-like metadata we can't tell all publishers/vendors to include/use this information … once we get too locked down into how to present the info we're going to get pushback from vendors
AvneeshSingh: one thing we have learned in gathering the feedback is that there needs to be flexibility - it looks like strict guidance right now but these are intended to be adapted. We had good discussion today. Let us see the further responses from participants who are on thanks giving holiday today. Raw original minutes:
https://www.w3.org/2022/11/24-pcg-a11y-minutes.html
Present: AvneeshSingh, chiara_dm, ChrisOliverOttawa, Gautier, GeorgeK, gpellegrino, Madeleine, mgarrish, kirsiy_Miia, Naomi
Chair: AvneeshSingh
Scribe:mgarrish
Topic: Feedback for User experience guide for displaying accessibility metadata.
AvneeshSingh: we were at daisy meetings last week after which there was an accessibility camp hosted by LIA Foundation, where we discussed metadata guide - received feedback from French and Italian groups.
AvneeshSingh: https://www.w3.org/publishing/a11y/UX-Guide-metadata/principles/
chiara_dm: I was part of the focus group and we gathered two groups and asked them about accessible reading in general and what the main issues are and then discussed proposed solutions for displaying accessibility metadata … first we asked what are the most critical problems and the answer was that complex books like textbooks with complex images, layouts, mathematics, etc. while simpler books like novels do not have issues … users want to know if images are described and they check if there is a preview to see if it accessible … want to know if they can read by paragraph, line and character to study the text and find spelling or words, etc. … want to know if books are pdf or EPUB, and whether EPUBs are version 2 or 3, want to know if there are headings, high quality tables … also DRM is important to know because it can block access to the book … whether fixed layout or reflowable is important because fxl can cause issues … users would like to have two levels of information - high level overview versus detailed info … first level would be short and concise - simple information about usability
gpellegrino: with this feedback and the French feedback from EDRLab we discussed different approaches to displaying metadata … the language for rendering the metadata should be as non-technical as possible whenever possible … accessibility features must be displayed or rendered in a harmonized way - with the same language - so it doesn't matter where users access the information … displaying of metadata should have two levels - first level may be a graphical icon with a few words that can be standardized … the second level would provide greater meaning - should be from the user's point of view, what they can do … third level would be schema, ONIX, MARC metadata … group metadata by area or purpose - translations should allow for some variations based on regional needs … the document should not enforce in which way the information is displayed - but should be structured … we may need to request changes to some metadata standards for example, it not easy to determine if content is screen reader friendly from ONIX right now … we also made some specific notes on standards but not important for this discussion … at the end there was discussion on what metadata is needed for the European accessibility act - some metadata to tell users that some books are not accessible
AvneeshSingh: the two levels of metadata is an important piece - we should not be obsessed about the translation of exact terms like screen reader friendly – for translation we need to focus on the definition of the terms, so that the translated term conveys the right meaning in that language.
GeorgeK: need to have a translation reference so we can get the metadata translated once without everyone having to do it separately
Gautier: Amazon is now displaying some information about accessibility … shows that text-to-speech is enabled, etc. … some systems won't make a link to xml resources, like certifier report, because it is a security threat
AvneeshSingh: what are people's views on having two levels - basic versus detailed? How do we define these two levels.
GeorgeK: I like the idea of exposing what the format is - may be just a simple statement in the summary - difference in metadata for a web page or catalogue versus what is inside the publication … I like the two-level idea - should just be reorganizing our guidelines
Naomi: for the format, we can probably identify that from other metadata and don't need it in the summary … for the two-level is this only about display in retail or changing the OPF metadata?
Gpellegrino: +1 to Naomi
AvneeshSingh: The two levels are only for presentation on retail side.
Gautier: some retailers won't implement the second level so the first level should state all the needed information - you don't always have a lot of space so you have to make choices … how to say you're not accessible because you have an exception - need to be careful about this - publishers may not want to state this so directly … need to talk to publishers in Europe about how they want to state this
AvneeshSingh: There is a code in ONIX to say publication is inaccessible. We heard from the accessibility camp that some small publishers may like to say that their publication is inaccessible due to excessive burden. On the other hand I think schema.org does not have metadata to inform inaccessible publication.
Madeleine: right, there isn't a way to say a publication isn't accessible in schema.org - had no accessibility features but that is different - way of not committing to saying what is present
GeorgeK: that a book may be inaccessible to some but not others is a real problem with making such a statement - need to know more about what is driving this
AvneeshSingh: right, we had this discussion in the accessibility camp. audiobook may be inaccessible to a deaf person but not blind
Madeleine: accessibilityFeature=none is still available in the vocabulary
GeorgeK: sounds like a statement that the accessibility is unknown because of an exception
gpellegrino: for this issue I would prefer a different point of view - need to say it is not compliant rather than inaccesible - more focus on conformsTo
Madeleine: +1 to Gregorio
Naomi: not meeting the conformance requirements of the accessibility act is not the same as being inaccessible - a lot of people can access all of the content - compliant v. non-compliant is a better way of thinking about it
MiiaK: I agree with gpellegrino and Naomi - I wonder if there is a risk with the two levels if retails only show one - the basic level might be the only one that publishers start providing
Gautier: accessibility metadata is part of the specification so it has to be present - if I don't create accessible content the metadata won't be there and there will be nothing for retailers to show - if I don't remediate a file because of an exception I won't add accessibility metadata - may be able to say that no metadata is available
GeorgeK: I don't recall if we have guidelines on what to do if there is no accessibility metadata. Still helpful to identify the format in the metadata even if the reading system can identify it
AvneeshSingh: next steps - we will have discussions on what is level one and two, what are the main metadata that are not accessibility information but that we want to include … I will create issues for these in the tracker to continue to discuss
GeorgeK: we may need to look at finishing the summary document before tackling the other work
Gautier: when a publisher does not include information the guide does say to provide a statement to the user that no information was provided
Gautier: From https://www.w3.org/2021/09/UX-Guide-metadata-1.0/principles/ : When a publisher does not provide any accessibility metadata for a publication, a statement should be displayed to the user informing them that no information was supplied.
Topic: Results of IFLA survey on use of MARC metadata in libraries.
kirsy: most of the libraries are producing daisy books … we will have a webinar later to discuss the results … 28 libraries responded - majority were from Europe … all have daisy books but half had EPUB … 15 use marc21 to describe the features of the book - has two fields: 341 and 532 … most libraries are not using both - some are satisfied with only using one and a few did not have tools to edit the other field … each library has a different way of displaying the metadata … asked librarians what they thought was critical for their users - all thought the type of publication is important (braille, etc.), then text, narration, navigation features - only a third felt text alternatives to images was important … it is important to give guidelines on how to use the metadata in a standard way
ChrisOliverOttawa: we are at an interesting point because there is a growing awareness of accessibility metadata and people aren't sure about the best way to do it
AvneeshSingh: It looks that having a crosswalk is not enough - also need info about how to use the fields
GeorgeK: is what we're doing here usable in the library community?
ChrisOliverOttawa: I think a lot of the communities don't have as close a connection to the publishers - seeing what retail is doing does condition the expectations of library users of the information - need to get a broader message out through IFLA
AvneeshSingh: we should have good liaison with IFLA
Topic: Update from accessibility summary leads.
GeorgeK: I have created issue 135 with everything I think needs to be done - one of the table heads is suggested summary - seems like more of an example - should we change it to "example statement"?
Naomi: +1
AvneeshSingh: https://htmlpreview.github.io/?https://github.com/w3c/publ-a11y/blob/main/drafts/schema-a11y-summary/index.html
GeorgeK: if there is a problem with identifying reading order - like choose your own adventure - there should be a statement … do we need more examples than the two that we have? only one in English and one in Japanese
GeorgeK: OK
AvneeshSingh: the group members may not be aware of the progress you have made. maybe you should send an email to the group and poitt to the relvant issues.
Original raw minutes:
https://www.w3.org/2022/11/10-pcg-a11y-minutes.html
Present: AvneeshSingh, Bill_Kasdorf, CharlesL, chrisoliverottawa, gautier, GeorgeK, gpellegrino, mgarrish, Naomi
Chair: AvneeshSingh
Scribe: gautier
Meeting minutes:
Topic: Guidance document for accessibility summary:
avneesh: let start with accessibility summary
GeorgeK: what I did was put in some values in the features table so there's simple language about what you should be doing and why... … do we want to continue with that approach?
GeorgeK: more example’s are needed in the table (ruby annotations, hazard, etc.)...
gpellegrino: the second column title (suggested summary) may be changed for a more clear title
Bill_Kasdorf: I suggest "Example summaries"
gautier: I have a use case for feature braille, the CBFU (French braille code)
gautier: in that case more information could be done for type of braille.
<Bill_Kasdorf_> Benetech/Bookshare routinely provides described math
CharlesL: describe Math is for images of math with alt text
Naomi: display Transformability I have use cases : reflowable epub with titles as images or table as image should indicate that display transformability is not fully possible (even if they are accessible by alt text)
Bill_Kasdorf: I have a client who puts Latex in their EPUBs
gautier: longdescription could indicate how they are implemented (details/ annexes, etc.)
George: mathML should detail if it's all math included as mathml (or only partial)
avneesh: if mathMl is used for chemistry, it should also be stated
Bill_Kasdorf: Another common distinction: Display math is provided as MathML, in-text math is plain text.
Bill_Kasdorf_: I have seevral use cases, and i recommend them to say plain text math instead of ASCII or UTF8 that is expert language
gpellegrino: i suggest to add some style to this table.
CharlesL: let discuss the other features by email
AvneeshSingh: tactile related values can be removed from this table, we can put it back when we have devices for reading tactile from EPUB.
Topic: Further Feedback for MARC crosswalk:
CharlesL: https://w3c.github.io/publ-a11y/drafts/a11y-crosswalk-MARC/index.html
chrisoliverottawa: i don't see activity on the immediate future. We've discussed with other experts, we want to keep in touch. We're preparing a position paper for more granularity of marc21. Someone from CELIA done a survey on accessibility metadata use and needs. She'll probably share it soon... … we see different push on the subject, we'll comeback on the agenda if we see some modifications to do in the crosswalk
chrisoliverottawa: it's fine to have this crosswalk still as a draft. Many persons have seen it, it brings discussions but in the library world there are many things actually. There will surely be movement in the coming year...
AvneeshSingh: can we make it a candidate report? (this mean it's better to not have too much changes after)
chrisoliverottawa: it will take a couple of years to move. We will use the crosswalk to support discussion papers. It may become more granular, so changes will be + not less.
Avneesh: It is time for this week. Thank you.
Raw original minutes:
https://www.w3.org/2022/10/13-pcg-a11y-minutes.html
Present: AvneeshSingh, CharlesL, ChrisOliverOttawa, Gautier, GeorgeK, gpellegrino, Madeleine, mgarrish, MURATA, Naomi, Tzviya, Bill_k
Chair: AvneeshSingh
Scribe: Madeleine
Meeting minutes:
Topic. Update from meeting with ARIA WG, at TPAC for proper implementation of DPUB ARIA roles in Apple's accessibility API, AXAPI:
AvneeshSingh: https://www.w3.org/2022/09/16-aria-minutes
Avneesh: update from DPUB ARIA
Charles: Met with James Craig to show him examples from Taylor and Francis showed how publishers are showing info with visual differentiators. And cleared up confusion on long post about priorities. It was followed by the Big meeting on Friday morning where Avneesh, George and Gregorio, joined on Zoom. Apple still has concerns about the roles and would like a smaller sub-set; their developers think some aren't needed. Top priority ones seem likely to be in the API but not the descriptions like chapter, glossary etc.
Charles: They have concerns about links to help screen-readers users skip quickly but our doc doesn't say what must be spoken. We explained them that this should be left to verbosity settings of screen readers.
Avneesh: the meeting felt more positive than previous meetings and James now understands more issues. But he is concerned about 37 roles. He thinks maybe 15 or 16 should be exposed to users. He also suggested the very highest priority roles should be in main aria spec as well as DPUB
Tzviya: after working on this for several years, what does this mean? what does this mean for roles considered less important?
Avneesh: if doc-chapter becomes chapter, doc-chapter will still exist. for roles deemed lower priority, we have made a good start getting many roles supported. Some tools support all roles, so if Apple moves incrementally at least they are moving
Tzviya: what about AT support for APIs
Avneesh: list of support: Google Chrome with Talkback supports almost all DPUB roles. Google Playbooks uses Chrome so it supports
Matt: did you get a sense if this effects DPUB-AAM mapping to get the update out that is hung up … wanted in parallel with EPUB. Can we continue to work on that update?
Charles: no other hang-ups raised so seems good, but if there is a specific issue we should check on let us know
Matt: hoping we can move forward with the ARIA module to CR. Maybe need to take up separately
Gregorio: Seems Apple will update the mapping internally. Upgrade to main ARIA roles is great for us and should get better implementation
Charles: table with AX API with AX sub-roles for landmark region or nil -- James agreed that nil could be changed to biblio-entry or whatever. Others should be able to map as well
Avneesh: objective is to update the AX API in the mapping but Apple needs to work internally first
George: Testing Android and Chrome, data was filled in for description. Is sub-class also filled in?
Charles: We didn't want to touch the description field. James agreed. There are localization issues.
George: TIES call should take a look at this in detail
Tzviya: With roles and subclass/superclass, there is a bigger issue with ARIA super classing. It doesn't work the way most of the ARIA group thought it should work. Inheritance structure is not clean
Matt: it is a theoretical model and doesn't work with all nodes. Tread with caution. Things may not inherit all properties.
Avneesh: things like list parent?
Matt: not the AAM mapping
Avneesh: We focus on AAM mapping, not main spec. James Craig wants to copy some of very essential DPUB aria roles to main specs, but our primary focus is on mapping.
Topic. Update from meeting with APA at TPAC:
Charles: The ADAPT is a new personalization module that is close to going to CR but the TAG has major concerns. We thought we answered everything so we though it was resolved, but actually it was closed because of lack of activity. So issues still need resolution … they love the mapping of symbols to phrases using the W3C registry … Can tag things in web documents with numbers and they can be converted to Bliss symbols automatically. Other areas where they had concerns is priority levels like critical to page vs medium priority -- reduce complexity on page for users who are distracted … more work needed in that area … were three modules, now four, but bring Symbols module to CR first and then go back to others
George: Synthetic speech: APA wants more features that were supported in the proposal from the Pronunciation task force … interlinear speech also wanted, where there are two things and you need to pronounce both or select which one … they want to enhance spec and want only one option while the current spec picks between two … not sure they mean one attribute only or one option
Makoto: The current doc has two approaches. One uses only one attribute but it has rich structures … other approach is multi-attribute approach … EPUB has been doing multi-attribute approach. … Now they have three but I don't know what the addition is … but they said they will pick one … I personally prefer a unified solution supported by browsers, online tests, and textbooks
Matt: They said they'd discussed with WHAT WG and had good response, but that they had some internal issues within their group … if they have buy-in, that's a sign of movement in the near future
Avneesh: May take years to get implemented even with browser buy-in … Wendy has action item to talk to publication community about interlinear text I asked them if we need to repeat the accessibility horizontal review for EPUB 3.3 family of specifications. APA working group said send change log and we will decide if review is needed. They mentioned that publishing community has high accessibility competencies so they are not worried too much.
Topic. Guidance document for accessibility summary:
George: Accessibility summary document has been updated
George: I updated several things. … Example section: added one thing and limited to 500 characters
George: removed priority column from features table. It didn't seem helpful … added text to Hazards based on discussion. What it is, where located, is it essential content. Added example … questions about features: 26 rows. Some are strange for EPUB … transformability, large print, high contrast. To me, not going to be used. Do we want to remove them?
Madeleine: is this doc for publishing community only? If not, maybe note that some rows are not as useful for books but are useful on the broader web
Naomi: Some of these might not be relevant for all books, but could be for specific book formats. … Or does it go up a level to the parent description, not the summary … the metadata display document -- User Experience Guide
Charles: some might not make sense -- if we have nothing to say in the suggested language column, why are we including it … could have a collapsed detail section about less popular items
Naomi: or just note it is not exhaustive
George: will add a link to the list of all features … then can remove ones that are built into EPUB from this document … concerned about children's book issue that Naomi raised, though
Tzviya: I disagree with others -- publishers struggle with summaries and the ones they have aren't helpful
Tzviya: having the guidance for what to say for each value would be really helpful for publishers to automate useful summaries
Avneesh: we have adjusted thinking on Summary
Matt: Schema.org was not thinking of EPUBs. It was more general. Summary not meant to be repetition of what is in the other metadata. … you could make it a duplication, but we are trying to avoid that now in this guidance document
Bill_Kasdorf: Tzviya's strategy would be an option; publishers that could write a good summary could keep doing that.
Matt: for EPUB where we are requiring this to be present, we know more what to expect in the metadata, so we can tailor the summary to what isn't conveyed in the metadata
Charles: some rows still seem to recommend duplication. But clarification might be needed for captions (video, not fig captions)
George: Will work on this, moving information into the summary to match table … I will remove some rows, make nice crisp text, and explain what we mean such as "all math is in MathML" so you can bank on it
Avneesh: Chemistry can also be represented in MathML so let's add that example
George: is anyone has comments on the new Hazards text, please let me know. Makoto, I need help with Ruby. If we use Japanese characters, what would the character limit be? Can you help with an example summary in Japanese
Makoto: Character limit not huge problem. Adaptation is not supported by reading systems. We need to promote Ruby rendering based on user preferences … if this book is expected to support both thoroughly annotated, partially annotated, and no Ruby, reading systems may not support this variety. … users may be disappointed by their experience based on info in the summary
George: this is true for math also, if the Reading System doesn't support the features in the book
Makoto: Systems can generate human readable info from the machine-readable metadata. … this could be automatically adjusted based on what the RS actually supports
George: I thought vendors would display metadata directly and not change it based on their implementation … if they don't support mathML, they shouldn't hide metadata that says the book has MathML. Same for Ruby
Naomi: For features we know aren't supported, publishers want readers to know the feature is there, but if the platform doesn't support it … it is misleading to say it is supported … leaving it in machine-readable metadata rather than summary lets vendor trim the metadata to what matches the RS tools … but the vendor shouldn't mess with the text of Accessibility Summary
Avneesh: this topic needs longer discussion
Naomi: when we do accessibility testing and something is a bit strange, like acronyms or other odd reading results, should we mention that … or is it common knowledge that acronyms will read poorly … there are ways to force a fix, but if we haven't should be mention it?
George: too much detail! don't put that in summary
Avneesh: We should move this discussion to the Summary task force next week
Charles: Might have ascii text for simple equations and mathML for complex. Also need to update acknowledgments of participants
George: Charles and I will get together and work on this
Topic. Further Feedback for MARC crosswalk:
AvneeshSingh: https://w3c.github.io/publ-a11y/drafts/a11y-crosswalk-MARC/index.html
Chris Oliver: Update on MARC: delays due to back to school season … interesting to hear the publisher input from the beginning of the production change since libraries are at the end … when feature is in the EPUB but the reader can't offer it, is it still in the EPUB file?
Naomi: Some publishers may be making custom EPUB for different vendors, but most make one EPUB for all systems
Chris: So users can't use the feature in their tool but it is in the file … when an EPUB is being prepared, and you get the manuscript from the author, is it is the publisher who decides on a11y features?
Naomi: different at different publishers. At Penguin/Random House, we have no contact with authors or editors, just get the file and move it to EPUB … but in some cases authors and editors are getting more involved … smaller publishers will have fewer people involved and may have more conversations about this
Chris: So do extended descriptions go back to authors for writing?
Naomi: in fiction publishing this comes up less. But it varies, can be author or epub team or others. Completely different across industry though
Charles: some publishers have conversion vendors and may pay that vendor to do descriptions. … if going for conformance they may be paying for it then
Charles: for how we display metadata, may want to add that if a vendor doesn't support a feature, they could note that features exist in book but are not exposed in this tool
Gautier: Image description is a major problem for publishers facing European A11y Act. French publishers association has a document about it. … varies by publisher, but because of EAA and back publication list needs, it is more important now … some conversion can be made by conversion team and some in house. … Big issue in Europe for publishing industry
Avneesh: Further discussion in the future. Thanks all.
Raw original minutes:
https://www.w3.org/2022/09/22-pcg-a11y-minutes.html
Present: AvneeshSingh, CharlesL, gautier, GeorgeK, gpellegrino, MadeleineRothberg, mgarrish, Naomi, Bill_Kasdorf, ChrisOttawa, Hong
Chair: AvneeshSingh
Scribe: CharlesL
Meeting minutes:
Topic: Updated Guidance document for accessibility summary:
AvneeshSingh: https://htmlpreview.github.io/?https://github.com/w3c/publ-a11y/blob/main/drafts/schema-a11y-summary/index.html
George: looking at the preview, we covered most initial items, let us go down to accessibility Features, should we just delete this whole section? The reason is, change in the WG with Accessibility 1.1 we changed the accessibilitySummary from a MUST to a SHOULD. Based on the schema.org guidance, AccessibilitySummary provides supplementary information, whatever the regular metadata does not cover now can go into the summary. We don't want to repeat information.
Naomi: Alttext depends on production, it may come from author, from an artificial intelligence etc.
Charles: For alternative Text we could include who wrote it.
Avneesh: Regarding putting in the list of accessibilityFeatures in AccessibilitySummary, we should not repeat it unless it requires some additional information.
Naomi: You may want to provide an example for the reader. It may be in appendix, if not in main document.
Chris: would be useful to have examples of what one might put there. Lets not loose these examples. They are valuable.
Matt: We shouldn't be stating production techniques, if there is a concern, if it is done by AI / crowd sourcing. I don’t think we don't want to get into the production side. things that we are not 100% sure of.
MadeleineRothberg: in keeping with new ethos with a11y summary. These examples were written when we were repeating information. these are just definitions, the only value would be to point out. like longDescriptions you could say that some have long descriptions but others may not. Not sure if we need feature by feature examples.
Bill_Kasdorf: I think this should be a accessibility Note not Summary.
Avneesh: that would be a schema.org change much larger issue.
Matt: remember this is tailored for EPUB but is still valid on the web in general.
Bill: we could say in pros that this is meant to be used as an Accessibility Note and not a complete Summary of all the accessibility features within this EPUB.
George: We can keep the Table and put in some examples with alternative text "This material was auto generated and may have errors" longDescription "This book contains long descriptions of importance to aid in the understanding of the content.
Naomi: Heading Structure could be affected due to the author's request to match the Print book. If someone went above and beyond. could point this out. "most of the images have well defined alternative text, but the images in some of the Notes may not have descriptions".
George: Hazards, we can just delete the table and include the summary.
Charles: I think we need to include this to tell the reader of additional detail of where this hazard occurs in the book. Eg: "If there is a motion Hazard, and accessibility summary point out where this occurs in the Book"
MadeleineRothberg: +1 to Charles on detail of where the hazard is
Naomi: I think we need this to remain a “SHOULD”. as an EPUB publisher, for back titles we might not know where the hazard is, because that information may not be available and would require research to figure out again.
GeorgeK: I hope to have these two sections by the 22nd since we have TPAC next week. Only thing remaining would be examples. If anyone can write up some examples you can do it yourself or send them to me.
GeorgeK: , I will work on getting what we discussed today implement by the 22nd.
Topic: Further Feedback for MARC crosswalk:
AvneeshSingh: https://w3c.github.io/publ-a11y/drafts/a11y-crosswalk-MARC/index.html
AvneeshSingh: Any comments on the Crosswalk?
ChrisOttawa: I have not received any feedback. The Libraries took a break for the Summer but will start meeting again next week. MARC21 is an encoding standard but it alone does not reflect the structure of the data. As a way to make a11y metadata forward look at make that data element more granular. whether there are other librarian colleagues to help with this effort.
Hong: I did contact some national libraries but they have not sent any feedback yet, but would be very supportive to the additional changes to MARC for accessibility.
AvneeshSingh: This sounds good, and are looking forward to any future developments you may have.
Topic: APA + Publishing community joint meeting organized on Thursday, September 15, at 15 UTC:
AvneeshSingh: https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2022#APA_.26_Publishing_Joint_Meeting
AvneeshSingh: , this is the agenda for the TPAC APA / Publishing WG/CG. In addition we will provide updates from our side.
Topic: Any other business:
GeorgeK: in our discussions over the past few weeks, people have pointed out that this is a really good point that we are removing and should move to the User Experience Guides. I have these as branches where we can go grab those texts and add them to the guide.
AvneeshSingh: We don't need to wait for accessibilitySummary document to be complete but we can work on these in parallel.
Naomi: I will create a GitHub Issue, about print page numbering and where those should fall in the text in a nonlinear book. Complex data structure and where the page mark should go. I will write up some examples where there can be a couple pages out of sync potentially.
George: could be a great example for the accessibilitySummary.
Bill_Kasdorf: Naomi, are you to physical page break markers should map to the print page.
Naomi: you may have a side bar and the main document on the print page, but in the digital version we may move that sidebar down the page where it makes more sense for the digital experience.. There may be print constrains and we may move the image to a different page. … , I need to sit down a write out these examples. … , what level of accuracy is needed. Which is more important good digital experience or keep the page fidelity of the print edition.
George: citations could get interesting.
gautier: Citation people in academics to paragraphs not to pages but is an experiment, but there is a lot of work happening on page reference. We will have to maintain two different ways to thinking. … , If we make it in a different way for the digital format. I have seen the MSWord page numbers, but has nothing to do with the printed page reference which is a big problem for scholars and from a reading systems (RS) point of view, in Thorium we have a "Where Am I" feature and we figured out with a RS we can't determine where the RS is really located at. We get a force page number, you think you are at page 3 but may be at page 4, and where the RS may be at different place.
Bill_Kasdorf: in some sectors of publishing "Reference & Legal" publishing and citations are very granular. However there usually is no print. We do have a locators TF at work so this may eventually get addressed.
AvneeshSingh: Looking forward to see the use cases on the issue tracker. Safe travels and see you all on the 22nd.
Raw original minutes:
https://www.w3.org/2022/09/08-pcg-a11y-minutes.html
Present: AvneeshSingh, ccarr, CharlesL, Gautier, GeorgeK, gpellegrino, Jeff_, Madeleine, Michelle_, Naomi, MURATA
Chair: AvneeshSingh
Scribe: CharlesL
Topic 1: Organizing meeting with APA group in TPAC:
AvneeshSingh: APA meeting?
GeorgeK: Pronunciation TF - emotion / poetry cadence etc. would require more work … , could be done in separate steps. It could be a topic for discussion.
AvneeshSingh: WAI-adapt
AvneeshSingh: https://www.w3.org/WAI/adapt/
CharlesL: gave an explanation of ADAPT
AvneeshSingh: Interlinear Text. (e.g. Opera parts). What do we think about this from publishing context?
Naomi: having a text academic - presented like a footnote on every line,
George: Like margin annotations.
Naomi: its not secondary, it goes along the main
GeorgeK: when a teacher marks up for grammar notes etc.
MURATA: this is used a lot in Japan. Ruby is a good example of this CJK characters. Over use of interlinear Text is a debate between the older generation and younger.
AvneeshSingh: APA may want our perspective of this.
GeorgeK: Unrelated to this topic, informing the W3C accessibility community about the wins in EPUB 3.3 is important. Some people in WAI W3C staff are quite interested in EU accessibility directive.
MURATA: We should invite the China publishing working group to this APA meeting. I have his email address. What is status of SSML?
AvneeshSingh: we will get an update on this from APA.
gpellegrino: Are DPUB aria roles under APA or not?
AvneeshSingh: DPUB roles are under ARIA working group instead of APA. Charles will get in touch with James Craig during TPAC.
gpellegrino: I will be also going to TPAC and will help Charles with that meeting with James
AvneeshSingh: APA proposed the 13th but we have our own meetings then. 15th of Sept looks better.
AvneeshSingh: 15th sounds like good and in the morning would be best for me and Gregorio.
Topic: Feedback for MARC crosswalk:
AvneeshSingh: https://w3c.github.io/publ-a11y/drafts/a11y-crosswalk-MARC/index.html
AvneeshSingh: review of MARC, thanks to Christine and Christopher for leading this work and thanks to Gautier for your work on transforming the Google Docs to GitHub HTML page. As discussed in previous call, we will keep the review open for some months for giving time to library community to respond.
Madeleine: I have not read through it. Chris is there parts of it which need feedback on? Or do you have a good handle on it.
Chris Car: EPUB and schema.org metadata could be converted to ONIX and then into MARC21 … , we would need to add subfields to hold a URL ?
gpellegrino: there is a ReSpec issue in the JSON. to fix this so it can be loaded completely. Is there respec for tables as this is a known problem. I don't have knowledge of MARC. for conformance not change to URL we may change it to a simple string. so new epubs
Charles: I don't see URLs being required.
Michelle_: ONIX to MARC who would do this. Libraries wouldn’t do this.
Chris Car: no that would happen upstream. ProQuest could do this for example.
gpellegrino: workflow you are expecting would be important to highlight at the beginning of the file.
Charles: Likes this idea
Chris Car: the last published crosswalk between ONIX and MARC is over a decade old. last one was the previous ONIX standard. We can check to see if they will be updating the crosswalk to the latest version of ONIX. … , what one thing would identify "Screen Reader Friendly".
Gpellegrino: https://www.w3.org/publishing/a11y/UX-Guide-metadata/techniques/epub-metadata/index.html#screen-reader-friendly
Gpellegrino: https://www.w3.org/publishing/a11y/UX-Guide-metadata/techniques/onix-metadata/index.html#screen-reader-friendly
Madeleine: if you conform to WCAG-A or AA if accessmodeSufficient of textual alone.
Chris Car: accessModeSufficient of textual would be enough? - Yes.
Madeleine: "Screen Reader Friendly" is a part of our recommendation to how to present this to users. Screen reader friendly is not a metadata by itself.
GeorgeK: OCLC does a crosswalk, do they also provide a transliteration? - No just the documentation … , is everyone writing their own software to do this?
Hong Cui: We haven't done any ONIX MARC request to OCLC - news release they accept ONIX data, OCLC members can send ONIX we should content them on how they do that.
Michelle_: any collaborative software conversion. There is not. ONIX is considered proprietary format, in any conversion is handled by the publisher. if there is something can be done open source, but would take a lot of publishers to bring their ONIX but would be great if we can do it.
gpellegrino: I am sure we could do something that is not proprietary.
Topic: Guidance document for accessibility summary:
AvneeshSingh: https://github.com/w3c/epub-specs/issues/2116
GeorgeK: the issue got raised to the EPUB WG I have only seen +1 to that proposal.
AvneeshSingh: we have given 2 weeks so we can resolve this and close this so accessibilitySummary will be a SHOULD not a MUST anymore. Matt will update the language in the CR. … , I will add specific action items.
AvneeshSingh: https://w3c.github.io/publ-a11y/drafts/schema-a11y-summary/
GeorgeK: that will trigger a complete rewrite of this document. accessibilitySummary now is only supplementary vs. inclusive as was done in the 1.0. spec. We can discuss it further in a call, could do the 18th at this same time. Charles and Gautier can make it. I can do a first crack at this (framework).
Topic: Any other business:
AvneeshSingh: lets meet on Aug 25th.
Raw original minutes:
https://www.w3.org/2022/08/11-pcg-a11y-minutes.html
Present: AvneeshSingh, gpellegrino, GeorgeK, zheng_xu, Gautier, CharlesL, chiaradm, Naomi, ChrisOliverOttawa_, ccarr, Michelle_, MURATA
Chair: AvneeshSingh
Scribe: zheng_xu
Topic 1. Should AccessibilitySummary field be mandatory or recommended?
CharlesL: https://github.com/w3c/epub-specs/issues/2116
AvneeshSingh: https://github.com/w3c/epub-specs/issues/2116
AvneeshSingh: first item accessibilitySummary
matt: we have some duplication ... we don't know if publisher might want to expose ... our conformance statement is not very clear ... so we turned to accessibilitySummary to have a bit more human readable information ... so that is some redundant information
Gpellegrino: +1 to Matt
Gpellegrino: same idea :)
matt: the accessibilitySummary can be machine processed but not as additional or extra information from conformance information
mgarrish: I’m beginning to wonder how much value our machine-friendly conformance identifiers add. Since we control what you have to express, we could just make plain English descriptions. For example, instead of “EPUB-A11Y-11_WCAG-21-AA” we require “EPUB Accessibility 1.1 – WCAG 2.1 Level AA”. That would make the conformance string the basic text that libraries need. It’s just as easy
Mgarrish: to pattern a plain language string as the truncated ones we have right now, and since they’re patterned they’d be just as easy for machines to process or translate.
Naomi: how we can maintain the summary and how user will perceive it.
mgarrish: The official definition in schema.org says this: "A human-readable summary of specific accessibility features or deficiencies, consistent with the other accessibility metadata but expressing subtleties such as "short descriptions are present but long descriptions will be needed for non-visual users" or "short descriptions are present and no long descriptions are needed."
Naomi: if the summary became something like we have to have all the a11y conformance item to be translated to summary then it could be a lot of work ... I wonder how we can put accessibilitySummary as practice
CharlesL: I have seen in some case the summary is just copy and paste so it's not what we are expecting how it works ... could the summary be a compromise from conformance item?
AvneeshSingh: I wonder how this could come into implementation
Naomi: there is absolutely a lot stuff we can clean up manually or automatically but the concern is if we would be conformable of making change. ... since some book can not be changed anymore according to a11y since we cannot make editorial decision instead of book author
CharlesL: An option as I mentioned would be to have the accessibilitySummary be a MUST if there is no conformsTo statement, otherwise it could be a "SHOULD" if there is a conformsTo statement included.
Naomi: it seems always need some manual process ... so, I am lean on accessibilitySummary is a bit complementary
gpellegrino: I agree with CharlesL. Some items can be automated by ACE
ChrisOliverOttawa_: the name accessibilitySummary might be a little confusing. When publisher wanted to advertise something like video does not have flashing but if the summary only tie to conformanceTo then it might be difficult to use
ccarr: I think I wouldn't rename accessibilitySummary. I think if it's a summary then it might need to be a summary of conformanceTo statement. If we need something complementary then we might need extra fields to let publisher to input
CharlesL: • EPUB-A11Y-11_WCAG-20-AA
CharlesL: • EPUB-A11Y-11_WCAG-21-AA
CharlesL: I agree we probably don't want to rename accessibilitySummary.
CharlesL: To the question to make it easier. in the 1.1 spec we have these type of data to specify version (EPUB-A11Y-11_WCAG-21-AA) and so on. I wonder if this is good enough or maybe we need something else.
mgarrish: we just expand it like "EPUB-A11Y-11_WCAG-21-AA" becomes "EPUB Accessibility 1.1 - WCAG 2.1 Level AA" ... it's still better than machine readable language and closer to human readable language
George: I like this idea then the defined strings needs to get into spec. Then ACE could check ... then do we have optimized specification ... then do we have consensus about if a11ySummary can be a requirement
ccarr: if we go with conformaceTo link I think we might need some general terms to explain what it conformance to in that link
Michelle_: in terms of aggregating contents how the accessibilitySummary could change content aggregation?
gpellegrino: we have machine readable meta data that can be produced by machine so you might be able to use
CharlesL: I agree accessibilitySummary is a conformance data in human readable way. We are defining some spec to let publisher to be able to tweak and use ... one concern from publisher is a11y also depends on reading system when putting accessibilitySummary
AvneeshSingh: we are expecting a11y v1.1 can move forward to recommendation in a few months ... so new suggestion might need to be moved to next version ... right now for the current version we will need some compromise ... For now, we can have AccessibilitySummary as recommended metadata, and we can add a note about where the accessibilitySummary must be provided. We did something similar for pointing to WCAG 2.0. Some of us wanted EPUB Accessibility 1.1 to refer to WCAG 2.1 level AA, but some parts of industry was not ready to make WCAG 2.1 AA as the floor. So, we decided that the floor would be WCAG 2.0 level A, and we provided a note that you should be using level AA, for meeting local legal requirements and EU accessibility directive.
Gpellegrino: +1 to Avneesh proposal
CharlesL: can it be a MUST or SHOULD
mgarrish: might hard to be a MUST to force people to add it
AvneeshSingh: for approach we will make issue tracker available to let WG comment ... we will make accessibilitySummary as recommended field that publisher can put it ... it's a recommendation from CG
MURATA: +1
CharlesL: To be clear accessibilitySummary we suggest changing from a MUST to a SHOULD be included from the CG
Topic 2. Any other business:
AvneeshSingh: Gautier has given a pull request for MARC cross walk, would you like to explain it more Gautier.
Gautier: https://github.com/w3c/publ-a11y/pull/125/files
Gautier: Thanks to Chris Oliver and Chris Carr, the updated draft for a A11Y metadata crosswalk including MARC21 references and definitions of properties is available for review at https://w3c.github.io/publ-a11y/drafts/a11y-crosswalk-MARC/index.html Adding the definitions makes the tables larger but also helps the understanding. Usability of the whole set will have to be discussed.
Raw original minutes:
https://www.w3.org/2022/07/28-pcg-a11y-minutes.html
Present: AvneeshSingh, ccarr, CharlesL1, Chrisoliver, Gautier, GeorgeK, gpellegrino, Madeleine, MURATA, Naomi_, zheng_xu Regrets
Chair: AvneeshSingh
Scribe: gpellegrino
Update from accessibility summary guidance document sub task force:
AvneeshSingh: https://w3c.github.io/publ-a11y/drafts/schema-a11y-summary/
AvneeshSingh: Issue #2116
AvneeshSingh: https://github.com/w3c/epub-specs/issues/2116
GeorgeK: there are concerns about adding Accessibility Summary on thousands of ebooks in Europe … plus the possible inconsistency between the machine-readable metadata and the accessibility summary which is free text. Another concern is that the accessibility metadata may change in the supply chain, so retailers should use an algorithm for creating accessibility summary from the machine-readable accessibility metadata.
CharlesL1: from Benetech perspective: for our certification program, we ask publishers and vendors to add it, it's been controversial. My view is that the accessibility summary is a field where to had additional information on the accessibility of the book (email address, specific works, etc.) … I think we'll continue to suggest to use this field. If it is not mandatory, we may get push back from publishers, I do not know.
Gautier: in the accessibility summary guidelines I've read "in some times this is the only information that will be displayed to the end user"
AvneeshSingh: some retailers may pick up only the accessibility summary and display it
Gautier: I think it is inconsistent with the UX guidelines for display accessibility metadata … I think we have to be more clear on this topic, it somewhat undermines the importance of user experience guide for accessibility metadata. in my view we should push to adopt the UX display guidelines
GeorgeK: very good point, we should encourage to display all the accessibility metadata … but I have concerns about the industry implementing our guidelines. at the same time accessibility summary can add some information that cannot be expressed in other metadata. for example the presence of the extended description is something that should be added in the accessibility summary. I have to work on the table in the document and maybe remove the sentence that Gautier cited
ccarr: we think that the accessibility summary is important for libraries so that we get the information from one field and not have to check in different places
GeorgeK: have you reviewed the UX guidelines?
ccarr: at this time there is no way in the library system to manage all the accessibility metadata
AvneeshSingh: if we make the accessibility summary as recommended field instead of mandatory field, does this affect you?
https://www.w3.org/2021/09/UX-Guide-metadata-1.0/principles/
ccarr: Ideally for the user I think it would be best to have it
CharlesL1: the conforms to is not a requirement, I think it is a SHOULD … from a developer point of view, it is super simple to manage the accessibility summary, instead of managing all the metadata
gpellegrino: maybe having a focus with librarians would help, maybe the accessibility summary can be generated my libraries starting from machine readable metadata … also a question: if the accessibility summary and the machine-readable metadata are inconsistent who wins?
zheng_xu: I think that we need guidelines for writing accessibility summary, if we want to have it as mandatory requirement. I think maybe is not the right time for making accessibility summary mandatory, we can make it mandatory after two or three years, when people start doing it correctly.
Naomi_: thinking about the backlist, thousands of ebooks, I think that creating automatic accessibility metadata can be quite simples (e.g. page list) … creating accessibility summary is quite expensive, also for maintaining, if we want to change modify the free text in the future, it is very complicated to update it automatically
GeorgeK: this document aims to provide the guidelines to publishers on what to put in accessibility summary. I think there are marketing opportunities in this free text metadata.
Chrisolver: Accessibility summary is very important. I think one concern on the library staff is the correctly wording of accessibility summary.
AvneeshSingh: Thanks for all the inputs. We are in CR stage, so we should invite inputs of as many people as we can. I'll copy-paste this minutes in the issue tracker and ask send email to EPUB 3 WG to invite more feedback.
Update from MARC cross walk sub task force:
Chrisolver: we've published a draft of the crosswalk … our proposal is to add a paragraph telling that it is a preliminary version of the document. in the library world we are not ready to make decisions. So we'll integrate the feedback we've got, and then move it to GitHub. I think we can do it in July … so if there'll be relevant changes in our domain, we'll get back on the document for changing it
AvneeshSingh: do you think we can start to review the document, or do we wait the move to GitHub?
Chrisolver: both for us is fine
AvneeshSingh: the Google Docs has problems with accessibility … in any case before publishing the document we'll have one or two months for reviewing it
Chrisolver: it may also take more time
Gautier: I can help in moving the document to GitHub
Chrisolver: Great. We will send you an email when we are ready for moving the document to GitHub.
Calls in mid-July to mid-August holidays period?
AvneeshSingh: what are your ideas for having calls during the holidays?
Maybe a call on the fourth week of July
I'll send the calendar invite
Action items:
- Chris Olver and Cristopher Car: Update the google docx for MARC crosswalk and inform Gautier for moving it to GitHub.
- Gautier: Port the Google docs to GitHub as HTML file, when it is ready.
Raw original minutes:
https://www.w3.org/2022/06/30-pcg-a11y-minutes.html
Present: AlexGrover, AvneeshSingh, Bill_Kasdorf, CharlesL, g_pellegrino, gautier, GeorgeK, Madeleine, mgarrish, Michelle_, MURATA, Naomi__, zheng_xu, ChrisOliverOttawa, LarsW
Chair: AvneeshSingh
Scribe: gautier
Topic: How can we improve the understanding of AccessModeSufficient: Issue #117 AvneeshSingh https://github.com/w3c/publ-a11y/issues/117
Avneesh: a lot of discussion happening on this issue. One thing is pretty clear from the comments that we do not want to work on changing the name of AccessModeSufficient property.
GeorgeK: textual,auditory vs textual (no comma) auditory meaning different things is very confusing. not having comma separated value would help (not possible in schema.org but may be in our recommendation.
mgarrish: comma is the only way it works when there are multiple modes unfortunately. epub's metadata isn't capable of handling lists of values
Madeleine: schema.org does not apply only to epub. We may be the only place where we document this but those metadatas can be used in other places than epub. This feature may be irrelevant to epub but need in other contexts. Anyway meeting the need of epub is high priority
mgarrish: the epub-specific changes we're discussing are only to be documented in epub accessibility techniques and display guides. we aren't changing the schema.org vocabulary (for others contexts). One solution is to emphasize the use of single values for sufficient access modes. those are the modes most users looking for an alternative to the defaults are after. Rare that someone wants an alternative with mixed modes.
AvneeshSingh: Yes, short term solution can be to emphasize single values. AccessModeSufficient = textual or accessModeSufficient = auditory means that a person with visual challenge can read it. AccessModeSufficient = textual or AccessModeSufficient = visual means that a hearing impaired can read it. Are we missing out something? Are there any risks if we follow this approach?
LarsW: epub that do need multiple modes for being sufficient exists.
Madeleine: it's "each entry should be one single line"
CharlesL: use case a book with undescribed picture will get "textual visual" (need the two sense to be consumed).
Mgarrish: AccessModeSufficient is not mandatory, it is recommended. We do not stop people from expressing multiple values, but we emphasize single values, so that users can know if there is a single access path that suits their accessibility needs. We can recommend not specifying AccessModeSufficient if the only value is going to repeat the access modes.
Madeleine +1 to Matt
AvneeshSingh: we have a short-term solution, emphasizing single values for AccessModeSufficient. We can do it in EPUB accessibility techniques instead of schema.org. For a longer-term solution we need to discuss it further, in upcoming calls. Lets move to other topics now.
mgarrish https://www.w3.org/TR/epub-a11y-tech-11/#meta-002
Topic: Update from accessibility summary guidance document sub task force: AvneeshSingh https://w3c.github.io/publ-a11y/drafts/schema-a11y-summary/
zheng_xu https://w3c.github.io/publ-a11y/drafts/schema-a11y-summary/#accessibility-features
GeorgeK: 4.4 is a big table. We should remove some items.
CharlesL: we should specify that accessibilityFeature = 'index' means there is a linked index useful for navigation thru screen reader
zheng_xu: for accessibilityFeature = 'latex' we may wait for a use case. (I do latex but it's converted to HTML).
GeorgeK: Removing bookmarks, ChemML, none, reading order, tactile object, unlocked
GeorgeK: next work is creation of examples
Topic: Update from MARC cross walk sub task force:
ChrisOliverOttawa: had a meeting with Marrakesh implementation metadata group. Crosswalk is important for them. Description of vocabulary (accessibility summary) is very important for Librarians. We have a big meeting next week, so there will be More feedback by next week
Hong: Just want to add to what Chris said, we have meeting on June 15, and we will get more feedback.
George K.: Why accessibility summary is so important for you?
ChrisOliverOttawa: Accessibility Summary is very important as it stands and communicates the Publisher efforts while file and other metadata can be modified by the vendors. It's easy to grab and display. So, librarians will value this accessibility summary.
Michelle_: there is a growing danger of lawsuits in universities and their libraries for accessibility non-compliant publications.
Topic: Next call:
Avneesh: I am booked fully in the week of June 20 to 24, so it would not be possible to do our call on June 23. This is an exception, should we meet again on last Thursday of the month, June 30? Luckily we have 5 Thursdays in this month.
Madeleine June 30 is fine for me
GeorgeK.: Better for me, it will give me time to work.
Avneesh: I see no objections. So, lets meet again on Thursday, June 30, at 14 UTC (same time as today)
zheng_xu: I added issue for latex here btw https://github.com/w3c/publishingcg/issues/37
Action items:
- Matt: Emphasize the use of single values of AccessModeSufficient in EPUB accessibility techniques.
- George: Remove the identified items from table 4.4
- Matt, Madeleine, Charles: Refine the confusing AccessibilityFeatures values in schema.org a11y metadata CG
Original raw minutes:
https://www.w3.org/2022/06/09-pcg-a11y-minutes.html
Present: AlexGrover, AvneeshSingh, CharlesL, chiaradm95_, ChrisOliverOttawa, GeorgeK, gpellegrino, JohnFolio (jf), mgarrish, Michelle_, Murata_, Naomi, zheng_xu_
Chair: AvneeshSingh
Scribe: CharlesL, gpellegrino
Topic: Proposed approval for Publishing the Guide for Audio Playback and Text-To-Speech:
AvneeshSingh https://w3c.github.io/publ-a11y/drafts/audio-playback/
AvneeshSingh: George and Matt worked a lot on this document, it is now time for review and approval.
mgarrish: yes it is an introduction for explaining the difference between text-to-speech, media overlay and audio-books … it is not super technical, it is more editorial
GeorgeK: It came up in different calls and discussions, this should be a point-of-reference for everyone talking about audio and digital publishing (in accessibility)
ChrisOliverOttawa: I've read the document and it was super useful for me, thanks!
JF: is this document going to be published as a working group note?
AvneeshSingh: very interesting, the major issue is that EPUB 3 WG is really focused on the EPUB format, while these documents are more broad (for the whole digital publishing industry)
JF: I understand, but since in the publishing a11y field the information are divided in different silos (W3C, CG, DAISY, etc.)... I see problems for newbies in the field
zheng_xu_: I think this is non spec document, but only an overview document; our goal as Community Group is to make the output of different task forces to become specs … maybe we can create an index page with links to all the different specs, I think this may be super useful
CharlesL: do we want to add note about the "read now" functionality of reading apps
mgarrish: Yes, I think that we can have an index page in the Publishing @ W3C... we may check
JF +1 Matt
AvneeshSingh: the publishing community group is a persistent group where discussions happen, the EPUB 3 WG, the audiobook WG, etc are more focused on specs (with a timeline)
JF: I understand, I still think that having an index page for linking to different specs is important
GeorgeK: to Charles "read now" seems more and action, more than a feature, should we add it?
CharlesL: Yes, I mean the functionality to launch the read-aloud
GeorgeK: ok, please check
AvneeshSingh: are we ready to publish this document or do we need some more time?
mgarrish: maybe we can vote for publishing, pending the Charles review
mgarrish: Proposal: approve publication of the audio playback guide pending review of the read aloud issue by Charles and George
GeorgeK +1
CharlesL +1
JF +1
AvneeshSingh +1
mgarrish +1
+1
ChrisOliverOttawa +1 not sure I can vote
AvneeshSingh: resolved
Topic: Update from accessibility summary guidance document sub task force:
GeorgeK: some items have been added to close some issues
AvneeshSingh https://w3c.github.io/publ-a11y/drafts/schema-a11y-summary/
GeorgeK: we have Gregorio here, we have a proposal language
gpellegrino: it is fine with me. Do we suggest to have multiple accessibility summary in more languages?
GeorgeK: normally one book is for one target, so I think it is fine to have only one
gpellegrino: ok, I think we should make it more explicit, and adding some info about lang attribute on the tag
JF: I don't think it is possible to put the lang attribute, I mean in the HTML specs it is not possible … for different languages we may put links in the accessibility summary
mgarrish: Specify the language in the OPF document it is required from the a11y specs … for JF: it is possible to define language in the OPF file (and also at metadata level)
Naomi: The problem here I see is that the EPUB doesn't support two languages (toc, ncx, etc.) … I think it is a different question
JF: I see the editorial considerations, but not the technical considerations … I don't see technical recommendations about formatting, tags, etc.
GeorgeK: I'll create an issue, and the I'll create a paragraph for this
JF +1 to i18n issues and lang markup George
GeorgeK: the thing of having flat text is common to alt-text and other standards
zheng_xu_: I think that having free text from the publisher in the accessibility summary would be great
mgarrish: I think it is not feasible to put markup in the package document … for this we've created the linked records in EPUB
JF: I fully understand, but I think this should be written explicitly somewhere
mgarrish: EPUBCheck checks for this thing, so an accessibility summary with HTML markup will not pass
JF: I'm looking for edge-cases
mgarrish: the specs doesn’t allow markup in the package document
AvneeshSingh: we should be independent from the format. We should figure out a statement which is neutral from the formats and then have links to EPUB specs, Audio Books specs etc.
GeorgeK: ok, John please open the issue. Regarding language issue, for me it is fine if we add a line telling that there should be only one accessibility summary, then we can merge with the main document
JF: ok, for my points I'll file an issue
GeorgeK: if people can review the section on conformance, it would be great
CharlesL: I think we should take care of the examples, for inconsistency
JF +1 Charles
GeorgeK: yes, I've an issue for that, we'll work on them after finishing the guide
Topic: Update from MARC cross walk sub task force:
Chris: Technical vs. editorial matches to library world MARC21 and says nothing about how to record the metadata. This is very familiar to me on the accessibilitySummary discussions :) … , Thank you Gregoria and Madeleine on accessModeSufficient which was very enlightening. Waiting for June meetings and feedback from MARC21 users/experts. June 6 Marrakesh group meeting / June 9 meeting and other meetings later in the month.
Michelle_: we aren't talking about discovery just well-formed access. would be nice to see what Librarians are using ie. products. how to grab and surface these access points
Chris: We are looking into a granularity within MARC21 so it can be machine actionable. could be a proposal RDA group. Yes this is very interesting and our greatest challenge we can record great metadata if 3rd party systems don't use it that is a challenge.
Michelle_: if we can get datapoints - customers who complain get things changed. If there are specific things in EBSCO / ProQuest . If there are things we need to put together a proposal I am happy to help.
AvneeshSingh: great call, great inputs, and looking forward to continued discussions on the issue tracker.
Action items:
- John Folio (JF) to create an issue for adding a note for technical guidance in accessibility summary document.
Raw original minutes:
https://www.w3.org/2022/05/26-pcg-a11y-minutes.html
Present: AlexGrover_, AvneeshSingh, CharlesL, GeorgeK, MadeleineRothberg, Naomi_, C_Carr, ChrisOliver, Gregorio, Lars, MURATA, Michelle_
Regrets: Tzviya
Chair: AvneeshSingh
Scribe: CharlesL, MadeleineRothberg
Topic: Update on extending crosswalk of schema.org accessibility metadata and ONIX to MARC.
Chris: We got some comments from Marrakesh group. At the June meeting we want to take them through the crosswalk. to get feedback. Not a lot of activity or in issue tracker. we have a question for the ONIX experts. offer to share ONIX metadata with us, we would like to map it out, the schema one is fairly clear, but ONIX is a little harder and we need real examples.
C_Carr: most NA authors has not adopted ONIX 3.0
g_pellegrino: I am available to share ONIX examples. … , Where would you like me to drop these? In ONIX version we have to focus on 3.0, since ONIX 2.0 is not maintained and a11y is really only been added to 3.0. and EU and is used by publishers / supply chains.
MURATA: The same in Japan
GeorgeK: Amazon last year started to require ONIX 3.0 to be delivered to them. this has incentivized to move to 3.0. Not sure where Education publishers are, but most Trade are moving to 3.0
Naomi_: I have nothing to do with the ONIX systems, our system can provide ONIX 3 happened 3 years ago. a year ago there were some small retailers can only take 2.0. some only could take spreadsheets. in the US the Amazon thing is really making a difference. there are always a few stragglers. I can get a list if thats helpful.
MURATA: I know Japanese publishers has our version of ONIX 3 not sure if all books have ONIX metadata but they are trying but 3.0 is heavily used in Japan.
AvneeshSingh: Gregorio, Madeleine and Charles spent a lot of time getting these into ONIX 3. Many of these accessibility codes are not in ONIX 2.
Chris: Chris Carr on the Canadian MARC committee in June with the official standards group to pass the mapping at that point to this wider audience to get more feedback / stability before we publish more widely.
AvneeshSingh: related to IFLA?
Chris: American research libraries an implementation of the Marrakesh treaty and get metadata to support it.
AvneeshSingh: Gregorio you will take on the ONIX..
g_pellegrino: Yes
GeorgeK: are you aware of the ABC?
Chris: Yes, this is more focused on students and faculty to launch a request, this library one direct to get the metadata into catalogs directly so no mediation can be done directly instead of via some 3rd party.
GeorgeK: DAISY we have a WG EPUB in Higher Education, publishers, RS developers, etc. presentations at CSUN, AHG etc. you can join us if you want.
Chris: Thank you, I will mention to Victoria Owen.
Topic: Issues raised by AccessibilitySummary guidance document team:
AvneeshSingh: https://w3c.github.io/publ-a11y/drafts/schema-a11y-summary/
George: list of issues provided.
AvneeshSingh: #95: https://github.com/w3c/publ-a11y/issues/95
George: Spoke to Rachel and got corrected text for issue and merged it
George: Would like to clarify Gregorio's statement last week that you produce AccessibilitySummary from the ONIX. But if there is a summary in the EPUB, wouldn't that be carried over?
Gregorio: In LIA, we started certifying before there was schema.org in the epubs. So we have an internal checklist we used to create ONIX metadata. Thousands of ebooks have only ONIX, not Schema. … From last year we are starting to also create metadata in schema.org so we can use a different workflow, but we are still ONIX centric. So we generate Schema.org from ONIX … we are working on a solution to automate accessibility metadata for previous books, but it would be derived from ONIX.
George: So these files do not conform to EPUB Accessibility spec because they don't have embedded metadata
Gregorio: Yes, we conform with LIA instead, which can be stated with the conformance statement. So we conform with WCAG for the reading experience but not with the Discovery aspect.
George: should we provide guidance for accessibilitySummary about this workflow?
Avneesh: we should keep the guidance general for summary, not specific to metadata formats.
Gregorio: the summary in ONIX is term 00 and the description is Accessibility Summary
George: maybe we should change wording in the guidance doc to "accessibility summary" to be more general rather than accessibiltySummary camel case
Gregorio: switch to description of file, then summary should say... Not if there is metadata, then summary should say....
CharlesL: we were planning to make scripts to look at schema.org metadata to draft the summary, but you are saying we should look at the file. I also asked if Richard Orme can look into this issue.
Naomi: Given all the different systems and tools, this will be automated in all different ways and this group can't proscribe it. We have books that have java script in them but it is never invoked and there is no interactivity, so if you scan for JavaScript you will get false positives. I do not think that we should come up with such an algorithm here. It would very specific to production process of a publisher.
Madeleine: did Gregorio mean to scan the books, or did he mean to be more general in the language of the guidance doc to be less tied to one system
Gregorio: I meant to be more general in the guidance document, to avoid tying to one system
AvneeshSingh: Our focus for the document should be to provide guidance for writing accessibility summary, algorithms for generating it automatically should be out of scope for this document.
Gregorio: So maybe the column header should be "is there mathML" not "is there schema.org accessibilityFeature=mathML"
George: Aim document more at principles and less at metadata
Gregorio: I will update the column headings to be less metadata format focused
George: I think we should also preserve the schema and ONIX values in the table
Naomi: I would appreciate a mapping to hand off to the person who does the ONIX
CharlesL: Could have a column with the generic wording, not call out schema or onix. Or could have a table with all of it.. extra column in addition to the different metadata columns with the generic information and then what you'd expect in each metadata … puts the crosswalk right there and also guides the summary … could separate out tables if this gets too complex
Gregorio: Prefer Charles' second proposal because as we add new standards it will get huge … maintaining that table becomes the whole cross-walk but that should be a separate thing
Avneesh: Tzviya raised issue that we should prioritize feedback from users
George: We could ask on various mailing lists for feedback
CharlesL: Vendors are starting to follow our advice on how to expose metadata. They have summary front and center and then bury all the details including hazards … so summary is very important … do we want to create a survey to send out to ask what would be useful info in the summary?
Lars: authoring guidelines should include writing summary in a clear and predictable manner
George: Yes, that's what we are working on
ChrisOliver: IFLA has just put out a survey to libraries asking about the metadata they are using or would like to include
George: We should find out what users want. Purchasers, professors and school districts that are selecting, different groups … tailor the survey to these different groups … Gregorio, when you update the tables, the first column will end up being called what? Features? Information to be communicated?
Gregorio: I'm not a native speaker so maybe George you should suggest a solution
George: Information object, but that isn't good. Information to be communicated
Charles: Facet? Hazards are not features
Avneesh: The purpose is to see what is in the metadata and describe it, so it could be "accessibility metadata" even if not format-specific
George: OK. Column 1, Accessibility Metadata, Column 2, samples of summary language. Then link to crosswalks for schema and ONIX. … do we put things in there or just link? People would appreciate the essential info and not just the link … link is canonical but this could be informative
Gregorio: question to Madeleine about crosswalk -- can we organize it with these headings? So that the link will be to the section for that piece of metadata?
Madeleine: we could put in anchors for each row if needed, as long as it is HTML
CharlesL: We would also need back linking to the summary document, wouldn't we?
George: can we put a little bit of info in the summary table?
CharlesL: no, it will be too complex
Gregorio: agreed, too complicated
CharlesL: We can put the link in the first column. Gregorio and I will work this out.
George: not enough time to discuss language issues and multiple summaries.
Naomi: was surprised to hear that Amazon is requiring ONIX 3 -- but that is only for physical books. Amazon still taking only ONIX for ebooks … correction ONIX 2 for ebooks
George: Action item to follow up with Amazon accessibility contact on ONIX 3 importance
Lars: Gregorio, Could use some files to test in our reader
George: AccessibilitySummary guidance sub-task force call next week at this time
Avneesh: Thanks to all
Action Items:
- Gregorio: Share the required ONIX examples wwith MARC team.
- George: Follow up with Amazon accessibility contact to check if ONIX 3 is a requirement.
Raw original minutes:
https://www.w3.org/2022/05/12-pcg-a11y-minutes.html
Present: AlexGrover_, AvneeshSingh, CharlesL, ChrisOliverOttawa, Gautier, GeorgeK, gpellegrino, MadeleineRothberg, MURATA, Naomi, Tzviya, Christopher, Lars.
Regrets: Bill_K
Chair: AvneeshSingh
Scribe: CharlesL
Avneesh: Let us switch the topics and discuss MARC crosswalk first because Madeleine and Tzviya need to leave in half an hour.
Topic: Update on extending crosswalk of schema.org accessibility metadata and ONIX to MARC:
AvneeshSingh: google docs: https://docs.google.com/document/d/1Lh0TwYHg574WFvdIAB1-Pns3fF7oSCjD/edit?usp=sharing&ouid=110044170227731414177&rtpof=true&sd=true
ChrisOliverOttawa: There is a draft, as a google doc we can now share it with the Marrakesh TF metadata group who are interested. They are providing some comments in the document. And we have issue tracker for this group. I will monitor both for comments. I resolved some editorial comments
AvneeshSingh: GitHub issue tracker: https://github.com/w3c/publ-a11y/issues/
ChrisOliverOttawa: One question on mechanics do people prefer meeting for those interested in the crosswalk, or prefer using online tools for the discussion
AvneeshSingh: Please use label "marc" for the related issues in the issue tracker.
ChrisOliverOttawa: I have heard folks are fine either way.
Christopher: work in progress not complete, I did add definitions for clarity for Schema.org and ONIX as they may not be totally equal.
MadeleineRothberg: are there things not clear or need more information or how they will be used to help you?
Christopher: in terms of MARC we only used 4 modes (auditory, textual, visual, and tactile) we didn't go further for math chemistry on visuals etc. Mode would be visual, but then the accessibility Feature math etc.
MadeleineRothberg: right for us the accessibilityFeature of math etc. would be accessible and be textual based vs. an image
Christopher: we can go back and refine this. we may need to add chemistry and modes and the accessibility feature if it is a textual mode or visual etc.
tzviya: accessMode vs. accessModeSufficient is very confusing. I still confuse the way it works, so even something like mathML can be conveyed in a visual way, we need to document this in a clear way. something like an image is visual but the description is that textual or visual and how you document that.
AvneeshSingh: in schema.org mathML is only used if there is MathML not an image of math.
MadeleineRothberg: the way we approached it if you have an image with alt text, the base resource is visual, but it has an adaptation ie. alternative text. so the resource has an accessModeSufficient of textual because that image has an alternative "textual" description.
tzviya: I am trying to limit this complex nuances into MARC if possible.
Christopher: we have sub-modes.
ChrisOliverOttawa: if you are going to filter for certain kinds of resources, we describe the base resource then we have accessibility features for each resource.
MadeleineRothberg: does it make sense to crosswalk the accessMode and features and leave accessModeSufficient for now
Chris: I think we have it might be at the very end. and does it make sense or should be review that.
Christopher: subfield has accessibility features, and would be for only one specific type, its a repeatable field. within it would describe it
MadeleineRothberg: there is a desire to pre-calculate if a user can use this resource which is where accessModeSufficient.
Christopher: we could put this as a note: this is textual Sufficient
MadeleineRothberg: ONIX can currently when accessModeSufficient if a resource is only access mode is textual, but combinations can be difficult to crosswalk potentially here.
GeorgeK: accessModeSufficient Textual is the trigger for Screen Reader Friendly as all images would have alt text etc. accessibilitySummary where the description could be determined by who is making this document and add that. Would be great to have that in metadata vs. a Note
Christopher: can we get some examples.
MadeleineRothberg: Does Gregorio have ONIX files?
tzviya: I can send you some metadata files from Wiley
Gregorio: we have some ONIX files we can share
Gautier: There is also the example used in the Display Techniques for ONIX document: https://www.w3.org/publishing/a11y/UX-Guide-metadata/techniques/onix-metadata/index.html#onix-example-1
Lars: Some sort of examples books with rich metadata to help implement UI to help the reader see what issues / features a book may have once it is downloaded. Person can get an EPUB which may not display the a11y metadata. especially display warnings etc. If anyone has publications to share that would be awesome.
George: Thorium is in the process on implementing that.
Lars: maybe Daniel has some example books.
AvneeshSingh: google docs currently the main way to contribute for now and we will move that to GitHub afterwards. I recommend to use GitHub for issues, hard to comment on google docs with screen readers, use issue tracker for that instead.
Gautier: could we switch to landscape. I would be happy to move the google doc back to GitHub once done. I estimate 2-3 hours to move that content over once finished.
ChrisOliverOttawa: Thank you Gautier! And excellent suggestions for the Google doc
Topic: Progress update on document for guiding, how to write good accessibility summary.
AvneeshSingh: https://w3c.github.io/publ-a11y/drafts/schema-a11y-summary/
GeorgeK: I sent out a link to the document which has it rendered in HTML, we have the github repo, I find it difficult to find the HTML view and sent it out last night.
Avneesh: it uses the respec tool from the W3C.
Charles: yeah there is a trick to using the rendered view of html files in github with github.io.
GeorgeK: I did label it with A11YSummary. did anyone have any updates for ONIX / MARC size of fields are limited are. ie 352 can be?
gpellegrino: ONIX that field is suggested to be less than 500 characters (maybe 250, I need to check) if this is a problem we can speak with Graham.
Christopher: if you run out of space you can add another one but would rather not do that.
Chris: examples that are in the document I can't see any of them being an issue.
George: we should mention in the example field, when we identify the length
MURATA: when you say Character… what do you mean one Unicode point but could map to 8 code points. European languages, what about emoji could require more code points.
GeorgeK: please create an accessibilitySummary for Japanese would be great. I would think a translation into Japanese, unless it doesn't translate well.
MURATA: I will make an example that is long to show the potential issues we may face.
MURATA: I volunteered to write an accessibility summary using lots of CJK variation selectors.
Charles: what about metadata being only in English, can we add lang attributes?
AvneeshSingh: AccessibilitySummary is not tied just to English.
GeorgeK: You can do Italian metadata right.
gpellegrino: Yes the accessibilitySummary can be in Italian which is the publication is in Italian. If a publication is in two language you could have multiple language tags in the metadata the first being the primary. Latin and Italian, the main language could be either if each are equal, but there would be 1 accessibilitySummary in the main language. French/Italian is for say the Italian market then the accessibilitySummary would be in Italian
MURATA: I have nothing to add.
Gautier: I agree what you have said. if you buy a book in another language that the summary would be in that language.
ChrisOliverOttawa: wonder if you could have two accessibility summaries? Say English and French. With this document the text for the accessibilitySummary the publishers if the book is in two languages.
gpellegrino: You can put different lang attributes in the metadata. the User Experience Guide would have to address this. Clarify the lang attribute may be a good suggestion.
CharlesL: issues regarding multiple conformsTo and how it is displayed and our guidelines when there are multiple statements in the metadata in our guide. Also what about in Canada with 2 official languages we should find out what Publishers are doing now or wish to do. as this is the first metadata which is human readable.
AvneeshSingh: Gregorio and Charles can take actions for creating issues on this topics, which we should address in next revision of User experience guide.
George: The mode of operating will be:
- Calls on the off weeks of the main A11y TF.
- Review the draft document and make corrections and additions.. GitHub will be used to control the document changes.
- Work on section 4 with the list of items to include in the summary.
- Use the issue tracker for all issues that come up.
- Fill out the large features table, which I think is section 5.
- Include examples that follow the guidelines.
- Include examples in CJK.
AvneeshSingh: next call May 12th.
Summary of action items
- Charles to add a github issue for multiple conformsTo statements and how to display them in our UI guide
- gpellegrino to add an issue for adding the lang attribute to the accessibilitySummary
- MARC and ONIX experts to check the maximum character limit for accessibilitySummary.
Raw original minutes:
https://www.w3.org/2022/04/28-pcg-a11y-minutes.html
Present: Alex_, AvneeshSingh, Bill_Kasdorf, ccarr, CharlesL1, ChrisOliverOttawa_, Gautier, GeorgeK, gpellegrino, Madeleine, Michelle_, MURATA, Murata_, Naomi_.
Chair: AvneeshSingh
Scribe: Gautier
Topic: Progress update on document for guiding, how to write good accessibility summary:
AvneeshSingh https://w3c.github.io/publ-a11y/drafts/schema-a11y-summary/
George: we have a draft we wish to finish. A small group of people raised hands for this work.
Charles: started as a group at benetech & daisy, and now this document is moved to W3C, using kind of structure usable for respec
AvneeshSingh: https://w3c.github.io/publ-a11y/drafts/schema-a11y-summary/
Charles: lot of publisher copy paste info for this summary. Making it of little use. Last discussion was is it useful to keep this summary? If done correctly it is beneficial.
Makoto want to join the group redacting this summary guideline
Michelle: will make it circulate to librarians so they can give their impression.
Charles: Purpose of AccessibilitySummary: some info is present in other metadata. This is where publishers can indicate WCAG level and shortcomings (example : all images described)
Charles: to be very informative. Some is potentialy automated (presence of video or alt text, etc.). Any automation could appear in SMART by Daisy.
AvneeshSingh: SMART by DAISY is already providing suggestions for AccessibilitySummary, Matt would like to align SMART with this document.
George: the idea is that professor selecting a title could easy determine if it meets needs. the same for any person wishing to read a book.
George: it came from publishers willing to be able to describe freely in a human narrated way. (example: this book can be read with eyes, fingers and ears)
George: some usecases also appeared where current metadata is not able to capture some important accessibility feature of a language. Example: there is ruby annotations in this book)
Makoto: we need a way to indicate characters table used (China, Japan don't use ALL CJK idegraphic characters in unicode)
Michelle: +1
George: there is also a pronunciation guideline group working. Some question appeared about 500 characters limit
gpellegrino: yes, it comes from ONIX, not a strong requirement but a suggestion. Some actors of the supply chain truncate so we need to speak with editeur.
Michelle: there are characters limits in MARC too but usually so high it doesn't matter. This could make library system timeout. We need a research to make sure what technologies allows.
Michelle: (the problem may come from library system more than metadata limit)
Bill_Kasdorf: 500 limit works for me
George: idea: a sub task force should meet next week same time to investigate this point
George: i'll send an invitation to everyone, come who wants
George: remember to use the issue tracker wisely : one question by issue.
Topic: Update on extending crosswalk of schema.org accessibility metadata and ONIX to MARC:
AvneeshSingh: https://w3c.github.io/publ-a11y/drafts/a11y-crosswalk-MARC/
ChrisOliverOttawa_: From Hong Cui: The length limit for MARC field is 9999 octets max. https://www.loc.gov/marc/specifications/
Gautier: describe table crosswalk
Charles: one confusing think was to find ...
Chris: not heard back from UniMARC committee
Chris: on marc21 side we had a primary meeting and have a preliminary mapping. But need more discussion to make consensus.
Chris: very practical issue:i have GitHub edit rights, but find it hard to use. So, I would comment on issue tracker etc.
Ccarr: https://www.loc.gov/standards/sourcelist/accessibility.html
Christopher: we also need a controlled vocabulary. This table will make our work easier.
ccarr: we used the docx document previously circulated. We would like to share but maybe not publicly yet
Michelle_: https://github.com/w3c/publ-a11y/issues
Michelle: the link that was shared in IRC is this the space for editing / commenting ? I have rights too, I can do this.
https://github.com/w3c/publ-a11y/tree/main/drafts/a11y-crosswalk-MARC
Charles: I'll break that table in multiple tables to make it easier to read
Avneesh: who will lead this sub task force?
Avneesh: any volunteer?
ChrisOliverOttawa_: I can volunteer to help lead
Ccarr: I can co-lead
Madeline: I’ll provide schema help
Charles: me too
Georges: Michelle said once this group do the work we have to take it to a wilder audience. Does that mean MARC community ?
Bill_Kasdorf: I think that was Michelle
ChrisOliverOttawa: yes
Georges: the goal is to have a strong draft for a wider review.
Georges: we have to keep people informed to invite them join in
ccarr: there are discussions underway at PCC but actually we can't add accessibility notes.
ccar: you can't say file format or drm presence actually.
ChrisOliverOttawa: Marc advisory committee has a full agenda. This would come in the next meeting (June). We may offer to add this mapping to this meeting.
Bill_kasdorf: from a publisher point of view. we not use marc commonly. it's coming and may be but book publishers don't use so much marc but they all use ONIX.
Michelle: ONIX will help for transformations
Michelle: automated transformation
Avneesh: A practical question, how would the leads want to take forward the work, through emails, issue trackers, con calls etc? Do you wish to discuss it first among yourself?
ChrisOliverOttawa_: maybe make sure we have all email. we need a meeting just focusing on marc.
Any other business
Original raw minutes:
https://www.w3.org/2022/04/14-pcg-a11y-minutes.html
Present: AlexGrover, avneeshsingh, Bill_Kasdorf, CharlesL, Gautier, GeorgeK, gpellegrino, MadeleineRothberg, mgarrish, Michelle_, MURATA, Naomi_, pcalarco, Yasmine, Hong, Chris
Chair: avneeshsingh
Scribe: gpellegrino
avneeshsingh: we have some new people, please introduce yourself
Yasmine: I'm Yasmine from IFLA, from the print disability section
Pcalarco: Good day, everyone!
Hong: Hi, I'm Hong from Library and Archives Canada
avneeshsingh: let's start!
Topic 1: Start document for guiding, how to write good accessibility summary
Avneeshsingh: https://github.com/w3c/publ-a11y/issues/86
avneeshsingh: we're having a great discussion in the issue tracker
GeorgeK: first question is: do we need an AccessibilitySummary, when we have User experience guide for displaying accessibility metadata. It sounds that we need it
gpellegrino: summarizing https://github.com/w3c/publ-a11y/issues/86#issuecomment-1077622631 … I'm now sure we need the field as it is now
Bill_Kasdorf: I do a lot of work with accessibility offices in universities, and they use that field a lot … for telling what they've done
mgarrish: Should we got back to the EPUB WG for make this field not mandatory? … since we don't have clear guidance on how to make this text
Gautier: I had a different opinion, publishers are waiting for a guide on how to write this summary … I now agree with what Gregorio pointed, maybe this information can be put in another place
Bill_Kasdorf: +1 to making it optional
gpellegrino: for me it would be good for making this field optional
GeorgeK: do the universities office distribute the files? Do they have a catalog?
Bill_Kasdorf: yes, we have the Frame system that report that field … for a resource remediated for a specific disability, it is useful to know it … like "i've only added image descriptions"
MURATA: My colleagues in DAISY Japan think that this field is useful, but we may abuse of the field, so we may split the field in two: the summary and other text metadata that doesn't fit
Bill_Kasdorf: even "may" would be okay with me
avneeshsingh: to summarize: no matter we want to make it optional or mandatory, I think we need a guidance for AccessibilitySummary. for matt: I think we should open an issue in the EPUB 3 issue tracker
Avneesh: for the guidance document: it should interpret the machine readable accessibility metadata and convey it in very general way, but should also convey the additional accessibility information which cannot be accommodated by machine readable accessibility metadata in the current state.
GeorgeK: I think that a guidance document is needed in any case … If we move it to the WG we miss part of the public that we have here (like libraries, etc.)
Chris: in a library system we have great expectation of metadata, but often accessibility metadata is not displayed, so having a summary is useful
Pcalarco: Chris Oliver is Head of Cataloguing at the University of Ottawa Library (Canada)
Mgarrish: https://github.com/w3c/epub-specs/issues/2116
GeorgeK: yes, I think this is a good point for deciding to maintain it mandatory or not
Charles: if it important for libraries I think we should maintain it mandatory … it is a requirement of GCA, but some publishers are making it using copy and paste … if we have a tool that generates the text it would be useful for publishers
avneeshsingh: I think we should postpone this mandatory VS optional issue
Bill_Kasdorf: I retract my support for may or should. The library case is compelling.
Michelle_: for libraries the problem to display metadata and making it available to librarians is a big problem … working closely with the teams that develop these interfaces I think that having this field is useful
avneeshsingh: back to the question: do we need a guidance document for writing the summary?
GeorgeK: yes we need guidance
Bill_Kasdorf: +1 to George
+1 to keeping it a Must and starting the guidance doc.
GeorgeK: I think that if we make the field optional, no one will use it
Pcalarco: George, I have not done this work before, but am happy to contribute
avneeshsingh_: maybe George can lead the group for the guidance document for accessibilitySummary, but we need more people to drive it.
CharlesL: I can help
GeorgeK: ok, we can update the document in the github and then send it to the group
avneeshsingh_: I think you can create a subgroup
Bill_Kasdorf: I'll be happy to participate
Naomi_: I'd also love to participate
Gautier: me too
gpellegrino: my colleague Elisa would love to participate
GeorgeK: it is open for other group members that want to participate
Topic 2: Work on extending crosswalk of schema.org accessibility metadata and ONIX to MARC
avneeshsingh_: after last meeting let's see the different action items
Chris: I contacted the person in the UNIMARC community, they want to know more … I've sent them the crosswalk, they'll send back some comments
Gautier: did you receive the document?
Gautier: the document is a list of a subset of accessibility metadata available in Schema.org … for each field I've put a note … as a glossary; for each information we have ONIX, Schema.org and MARC … for UNIMARC it is quite simple to map ONIX 196 codelist to UNIMARC … instead we have few information from MARC21 … at the end of the document I've put a table with two columns: one for UNIMARC and another for MARC21 … the goal is to complete the columns and put them in the crosswalk
Chris: thank Gautier, I've share this document with my colleague, we're setting up a discussion group for analyzing the document and give feedback … we'll have a meeting next Wednesday
avneeshsingh_: where do we put this document? … maybe in github?
Michelle_: for me github is fine
Chris: for me is unusual, but it is fine
avneeshsingh_: maybe we can put it in a github wiki
gpellegrino: manage tables is complex in wiki
Bill_Kasdorf: Could somebody provide a link to a Github guide?
Gautier: is there a guide? … for github
avneeshsingh_: maybe we can identify one or two editors familiar with github … I think a lot of work will happen in the different MARC working group … and in the document we only collect the results
Michelle_: I can help in github
Chris: fine for me
Gautier: There are guide here : https://www.w3.org/Guide/
avneeshsingh_: who can be the editors?
MadeleineRothberg: I can join as a schema representative
Gautier: I can partecipate in the task force … maybe it would be to have a definition for each metadata … for mapping and for localization
Hong: I would love to participate in the crosswalk, I notice that for most of the metadata is mapped to ONIX, but some links are missed
Pcalarco: MARC reference documentation is at https://www.loc.gov/marc/bibliographic/
gpellegrino: I can join for the ONIX part
CharlesL: for the definitions are we defining the fields or the values?
avneeshsingh_: I think it will depend … the group can decide
CharlesL: https://www.w3.org/2021/a11y-discov-vocab/latest/
avneeshsingh_: I'll open the invite for the task forces to other people, thank you for the work, have a nice day!
Members of sub task force for Guidance document for AccessibilitySummary:
George, Charles, Pascal, Bill K, Naomi, Gautier, Elisa
Members of sub task force for extending accessibility metadata cross walk to MARC 21 And UNIMARC:
Madeleine, Gregorio, Gautier, Michelle, Chris, Hong
Raw original minutes:
https://www.w3.org/2022/03/24-pcg-a11y-minutes.html
Present: AlexGrover_, avneeshsingh, Bill_Kasdorf, CharlesL, Christopher_Carr, Gautier, GeorgeK, gpellegrino, MadeleineRothberg, Michelle_, Miiak, MURATA, tzviya, Chris Oliver, Kirsi
Chair: avneeshsingh
Scribe: MadeleineRothberg
Topic 1: Work on extending crosswalk of schema.org accessibility metadata and ONIX to MARC
Avneeshsingh: https://w3c.github.io/a11y-discov-vocab/crosswalk/
avneesh: UniMarc or Marc21
Michelle: There are even more but those two are fine to start
Gautier: France is waiting to see a complete set before adding to Unimarc. They are watching what we do. … Unimarc has a mapping for ONIX 196
Avneesh: we should have a liaison to that group
Gautier: I will encourage them to join us
Chris Oliver: Also on IFLA committee on standards. Permanent UNIMARC Committee reports to them. They will be interested and I can make a contact there
Avneesh: Is the crosswalk for MARC21 also in progress?
Gautier: I started to make a table with MARC21 and UniMarc and I would like to have it reviewed by MARC and UniMarc specialists. I can publish it as a work in progress.
Chris Oliver: Chris Carr and Julie Cardinale have been wanting this mapping. We may need more granularity to ensure we retain all the richness of the metadata
George: Interest in Marrakesh means we should ask WIPO-ABC to add the metadata to their system of records as people start providing it.
Avneesh: that might not be needed for a little while yet. This step is after we have the mapping complete.
Chris Oliver: Library of Congress (LOC) has announced they will use MARC fields. Vocabularies are also important. Also how to display to the user is important, as this group has been working on
Avneesh: Either this work goes on in another group and we collaborate with them, but if no one is doing it, we could start it in this group. What do people think?
Christopher_Carr: Canadian Committee on Metadata Exchange created the fields but didn't get good uptake. LOC needs a vocabulary list before they can use it and we want to use W3C vocabulary … also working with audio video catalogers group who are interested in helping with the vocabulary. LOC is also interested in helping but the effort got stalled … Libraries have guidelines to say use accessibility markup but no details. I'd like to help move this forward.
Michelle: I suggest working with the Genre Form groups rather than Subject Heading, if it fits in the 655s. … controlled vocabularies are handled differently than the fields. … work on new ways to use MARC fields is in progress in the Music group
Chris Oliver: Need to know what the cross-walk looks like before we can make a concrete proposal. Make a working group to look at cross-walk that Gautier has started … then go to committees such as Canadian CME to make a proposal. … See what we need to add. More subfields? Just vocabulary? … RDA has an accessibility content element. No granularity. Could create a more granular implementation to connect to RDA data model through that element … Or bring a proposal to RDA for greater granularity … Could be a good time to push for more standards since equity is on the agenda everywhere
Charles: Good to hear MARC has some work in place. With ONIX, we saw what was already there and suggested some new fields. … Same approach here? Start with experts on both sides to see what is already matching and then see what is needed
Michelle: Does the crosswalk reflect the actual state of MARC records in other platforms? There's a lot of wonderful work by people making MARC records doing all sorts of things that discovery systems don't use … want to be functional and useful in the real world?
George: Vendors like VitalSource and Red Shelf and NELS in Canada have done some mapping. … vendors display accessibility metadata in their online catalogs so professors can see it, students can see it … Would love to see that in libraries so patrons can find items they can use … My understanding is that MARC has a bucket for a11y but no details
Michelle: there are tags inside the field, but it is one field. … There are other ways to manipulate MARC for example Genre Form fields
Michelle_: https://www.loc.gov/marc/bibliographic/bd341.html
Michelle: Need to investigate if systems are exposing 341 for users
Charles: Discovery is very important to us, so we do want to enable that
Kirsi: There is also another MARC21 field 532 Accessibility Note: https://www.loc.gov/marc/bibliographic/bd532.html
Charles: start with mapping and then also work on discovery interfaces
Tzviya: The 341 list looks like it will fit in well with our previous work. Implementation isn't needed for this level of W3C work, but we will want to get this out for inclusion and then eventually systems will adapt it … European Accessibility Act requirements will be a big help, just need to get the mapping to everyone who needs it
Bill: Would be great to use this in WorldCat. I have contacts at OCLC. Maybe we should get someone there involved
Avneesh: Yes, after cross-walk and after missing pieces are filled in, then we talk to WorldCat and Accessible Book Service
Christopher Carr: Second field is 532 for Accessibility Note, human readable description of features, hazards, and things that are lacking … No one has implemented because there is no vocabulary to fill the 341 field … No, not hazards. But that might be able to be added … We looked to match Schema.org list so it should work well together … good for all materials in library, not just print, which is great … If we approach LOC with a stable vocab with a stable supporting organization, they may be more open to it … For Canada we would need it in French as well, which we would need to approve
Michelle_: For discovery purposes, the 532 will be hard to index
Gautier: Cross-walk could have surprises. Many of the fields we need may exist in MARC outside 341, but we need to go and find them. Reflowable, pagination, not flagged for a11y but are there … We should collect list of people using this info
George: Is 532 a direct map to our summary field?
Charles: Sounds like
Michelle: Depends how it is used, could be
George: EPUB has schema.org inside, but ONIX is external. Which will be either for MARC systems to ingest?
Bill: LOC would need the vocab to have a permanent home. Is W3C recommendation appropriate? Is Registry needed?
Avneesh: Those are difficult decisions, for later
Chris Oliver: Best practices and guidelines are very important for helping people use the new metadata
Avneesh: UniMARC is further along. MARC21 is looking promising. We should start by filling out the cross-walk to see if there are gaps. … First step is the cross-walk which Gautier has started
Gautier: Work was started in French so needs some adaptation to share in English. Will try to do for next week.
Chris Oliver: add me to the mailing list, and also Chris Carr
Michelle: I can also join the mailing list
George: I will send out a link for joining
Topic 2: Start document for guiding, how to write good accessibility summary.
We do not have time today. George had a question, now we have user experience guide for presenting machine readable accessibility metadata in a user friendly way, so do we still need AccessibilitySummary. If most of us think that it is still important then we can start the work. Please comment on the issue.
Avneeshsingh: https://github.com/w3c/publ-a11y/issues/86
Avneesh: Thank you everyone for this great call and for the new experts who have joined us
Original raw minutes: https://www.w3.org/2022/03/10-pcg-a11y-minutes.html
Present: Alex_Grover, avneeshsingh, Bill_Kasdorf, CharlesL, Gautier, gpellegrino, MadeleineRothberg, mgarrish, Naomi, tzviya, zheng_xu, GeorgeK, MURATA_, Vince
Chair: avneeshsingh
Scribe: mgarrish
Topic: Plannning for next revision of User experience guide for displaying accessibility metadata.
avneeshsingh: first version of the user experience guide was released last year as we needed feedback. And we've received our first from Gautier at EDRLab. Also, we are waiting to have feedback from Italy and U.S.
avneeshsingh: we planned to start a new revision in this timeframe as the new EPUB Accessibility specification is going to CR so we need to update the guide for this new version
Gautier: avneeshsingh has sent the feedback to the group email so I won't provide full review - we translated the guide into French and held four workshops with 40 persons … we're looking to find out if the information is useful to users and also if it is easy to implement
Avneeshsingh: User experience guide 1.0: https://www.w3.org/publishing/a11y/UX-Guide-metadata/principles/
Gautier: we were asking general public feedback thru retailers and librarians, even if AT users and libraries for blind were participating, they were few. The feedback we had was not very good, we synthesized the reactions to six items. felt the wording was overspecialized, but may not be in scope of the work we have to do now - potentially a localized problem with the translation
GeorgeK: we use the term screen reader friendly but if that term is not used in French then the localization could be the names of the AT (Jaws, etc.). Would that kind of localization help?
Gautier: what we see is using more generic terms
avneeshsingh: we can discuss the wording details later on
Gautier: we will have several workshops about wording that we can share but we think it is a localization problem. We also found that some information is missing, some users are interested in the format and whether there is DRM … we have strategies to handle this, but came from all users … this information is useful to all readers, too, not just for accessibility … look at broadening the meaning of accessibility as applicable for all … also had difficult with mapping to onix and marc, need more work on this … after this feedback we made a proposal to the participants to reorganize the information
avneeshsingh: there are several pieces of the feedback that we need to think about how to make localizable I remember when I started working with DAISY board on strategy, the board members from Europe suggested us not to use term print disabled because there is no equivalent word in their language. So, localization considerations are important. … we are interested in extending the schema.org/onix crosswalk to add marc … but first we need to figure out scope issues … the design of the guide was specifically for accessibility metadata - this feedback includes fixed layout, format, drm, but it is confusing where these lie … the information is generally useful to all users - more generic properties … drm is another example of what all users would like to know - helps accessibility but not specific to it … should all these items be part of the accessibility metadata guide?
Gautier: there is a lot of importance in knowing if a book is reflowable or fixed, example for readers with dyslexia who do not use screen readers and need to know if content can be controlled
GeorgeK: some of these things are not accessibility-specific. I see on VitalSource that they say fixed or reflowable but what they mean is it is PDF or EPUB, but an EPUB can be either fixed or reflowable … I would see adding a section that is geared toward more general information about the book … can discuss the higher-level items that are broadly useful to know … drm is added after the publisher distributes the book so it is the responsibility of the distributor, but we could recommend that they include information about the impact of the drm on accessibility like whether you can copy and paste … adding page numbers in the section would also really help
MadeleineRothberg: the proposal for grouping the properties is a useful idea and perhaps that will be a way to approach the general information … we worked only on the accessibility metadata itself but we can expand to metadata that isn't in these specifications … so if you have information from other sources here is how you can integrate it
gpellegrino: perhaps we can add an appendix to handle this information since it is not directly accessibility related but important for the product page … it is not a specification so we don't have to mandate what to include
CharlesL: we started this with just the accessibility metadata so pointing out the other information is useful … we could also provide a glossary of terms that explain what we mean to help with understanding and translation
tzviya: a comment about drm and whether it gets in the way of accessibility - publishers cannot provide this information
Gautier: the user is sometimes able to pick the drm at the time of download - the bookseller can let them know the issues … I believe a set of definitions would be really useful, too
vince: there are problems with the platform and reader that can cause problems - like MathML support
avneeshsingh: the schema.org accessibilityFeature property helps list these
GeorgeK: we need to bring any changes regarding the generic metadata section to the larger group before implementing because there are implications beyond this group … we need to get feedback from as many groups as possible and incorporate their concerns so that we meet their needs … we need to ensure the principles and guidance that is universal and can be translated so that we don't get different implementations
CharlesL: we lacked expertise for MARC harmonization when we did the first version - need help to build out the mappings
Bill_Kasdorf: I could recruit a MARC expert who might be able to help.
Gautier: I work with two people on unimarc but that's not marc21
avneeshsingh: from the discussions so far the existing scope on accessibility metadata looks fine, but it looks like we'll also elaborate to include the more universal metadata … it is okay to have this kind of section where we can suggest drm, fixed layouts, etc. for the generic metadata section, where there is information like Title, Author, ISBN etc.
avneeshsingh: another question is the timeline issue - we have the French feedback but not yet from Italy or the US … I expect this work will continue throughout the year as we'll need to harmonize all feedback
… let's start with the French feedback but also look to integrate the additional feedback we expect
Gpellegrino: Yes, we plan to seek feedback from users in Italy.
GeorgeK: I'm not sure who in the US is planning to provide feedback - I don't know of an organized effort
GeorgeK: once we start the marc discussion we'll bring in a wider group of people but not sure where that sits in timeline
MURATA_: we have requirements specific to Japanese community - we haven't gotten into exactly how this will be done
avneeshsingh: we don't have to rush the Japanese feedback. We are improving the guide in iterations, we should release next version towards end of this year. And then keep on working on it based on further feedback.
CharlesL: would extra spacing and vertical issues require new features?
MURATA_: different opinions on this but you will have to embed some information in an EPUB
avneeshsingh: can you recruit some marc21 people before the next call Bill_Kasdorf?
Bill_Kasdorf: yes, I should be able to get someone within the next week? … I'm on a NISO working group where we have some librarians that use marc routinely … marc is impenetrable to people who don't use it routinely
avneeshsingh: we can discuss unimarc and marc21 in the next call
GeorgeK: do we want to reach out to any other groups? I can ping some people from Canada
avneeshsingh: accessiblity summary comes up a lot - we were assuming publishers would provide details in this field and accessibility features will be reported in Accessibility Summary also. This will reduce the need to list the accessibility features. but it doesn't look like feedback from EDRLab included anything about it.
Gautier: I'm not sure how to integrate the feedback with the github tracker
MadeleineRothberg: AccessibilitySummary versus a list of features depends on which are available - the people reading this guide don't have control over what is provided so we can only suggest how it be used … perhaps we need to say if the summary is available you need to make sure readers can access it … sounds like we should elevate some accessibility features into another interface rather than grouping everything else
tzviya: in the epub specification there is a delineation between the requirements of the epub and the reading system - I can put a lot of things into the metadata that may not get used
MURATA_: +1
tzviya: not sure if the summary is useful to users - we add it but would like feedback on how it's used
avneeshsingh: we have a plan to write a guide on how to author summaries but it keeps getting delayed by the work on the User experience guide … could you provide feedback on it Gautier?
Gautier: from the user's perspective it was not seen as helpful because it may not be written well - but if we have guidelines on how to write a good summary that would be helpful
GeorgeK: the accessibility summary was introduced to provide an easy to read description - now that we have a guide that explains how to translate the metadata into something that is easier to read the importance of the summary is reduced … publishers are looking for a boilerplate summary that isn't customized for each title so it further becomes less useful … there is also a 500 character limit imposed by some vendors so the future of summaries is uncertain
CharlesL: adding a summary is required by the accessibility specification and all GCA publishers are adding it with detailed information - also meant to have specific information about issues that aren't covered by the general metadata
Naomi: we are putting summaries into all our titles but it is formulaic based on the hazards - we may add more information in the future - the summary explains the other metadata; it does not repeat it
MadeleineRothberg: summary was also meant for niche cases that are not easy to explain through the regular accessibility metadata
CharlesL: +1 to what MadeleineRothberg said exactly!
Avneeshsingh: We are out of time, it looks we will need some sub task forces for moving different things forward in parallel. Lets meet again on March 10. Thanks to all.
Original raw minutes:
https://www.w3.org/2022/02/24-pcg-a11y-minutes.html
Present: gpellegrino, Madeleine, Miia, CharlesL, Alex_Grover_, zheng_xu, Bill_Kasdorf, Naomi, Gautier_Chomel, laurent_
Regrets: George, Tzviya, Matt_G
Chair: avneeshsingh
Scribe: gpellegrino
Topic: Continue identifying important DPUB ARIA roles
avneeshsingh: https://docs.google.com/spreadsheets/d/1atUkcAbkHpS5eUJ1rdDCrQ3saY8HZEMTNtWkanASLo4/edit?usp=sharing
avneeshsingh: doc-footnote
gpellegrino: I think it is important to identify since there is no clear heading for it
CharlesL: yes, not like glossary, ecc.
gpellegrino: it is important to identify them, because they are normally identified graphically
Alex_Grover_: yes, sometimes are at the end of the HTML file, other are on the end
avneeshsingh: important or critical?
CharlesL: for me critical
zheng_xu: what does it mean "critical" or "important" for reading systems?
avneeshsingh: The main target for us is user experience. There are some roles like footnotes for which reading systems do a specific behaviour(s), but here the objective is not to write reading systems guidelines, it is not in our scope.
gpellegrino: those importance are for screen reader
CharlesL: yes, we are defining these different levels for assistive technologies and for the ARIA implementers
zheng_xu: thank you
CharlesL: doc-glossary
avneeshsingh: normally there is an heading for it
gpellegrino: maybe for me it can be a "medium"
avneeshsingh: we also have "index" in "medium"
CharlesL: good
avneeshsingh: any objections?
CharlesL: doc-introduction
gpellegrino: normally there is an heading for it
CharlesL: maybe we can move to medium
zheng_xu: what is the difference between high and medium?
avneeshsingh: we use "high" for identifying parts that cannot be understand differently (no headings, ecc.)
CharlesL: doc-notice
avneeshsingh: I think it is high... any objection?
CharlesL: doc-part... it is the same as doc-chapter
avneeshsingh: fine... any objection?
CharlesL: doc-prologue ... normally there is an heading for defining it...
gpellegrino: from me medium
Alex_Grover_: we have prologues without headings (for examples for fantasy)
Naomi: yes, for examples for novels (e.g. the heading may be "Six years ago")... I think it should be at the same level of doc-introduction
avneeshsingh: ok, medium
CharlesL: doc-pullquote
avneeshsingh: high
gpellegrino: yes, you can identify them only by their graphical layout
CharlesL: what about "critical"?
gpellergino: nope for me
avneeshsingh: ok high
CharlesL: doc-qna
avneeshsingh: it depends from the context
gpellegrino: I see some possible usage in webpages
CharlesL: we can keep it as "high"
avneeshsingh: any objections?
CharlesL: doc-subtitle
gpellegrino: for me is high, because it is "incorrect" to use
Naomi: I think on the web there are several usage of things similar to subtitles, I think we should explicit the correct use of the role
avneeshsingh: ok, we update the comment
CharlesL: doc-tip
avneeshsingh: George thinks it is important for example in manuals
CharlesL: I think it is high
avneeshsingh: any objections?
CharlesL: doc-index... we decided it last week
gpellegrino: It is the only actionable that is not critical
gpellegrino: we now have the search function in reading systems
CharlesL: doc-appendix
... medium
avneeshsingh: any objections?
CharlesL: doc-bibliography... medium
avneeshsingh: any objections?
CharlesL: doc-bibliography
CharlesL: doc-conclusion... medium
avneeshsingh: any objections?
CharlesL: doc-example... we moved it last week
Naomi: I think the issue is that there is already the
tag to which example is applied... sometimes it is enoughBill_Kasdorf: A code example wouldn't be an image--would that still be in
?gpellegrino: as far as I remember doc-example can only be applied to figures
zheng_xu: maybe it can be an high
Ggpellegrino: https://www.w3.org/TR/dpub-aria-1.1/#doc-example
Bill_Kasdorf: does a code example inline can use doc-example?
Naomi: figure can contain also text
gpellegrino: https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-code-element
gpellegrino: you can use tag
Bill_Kasdorf: I see, but for most publishers it is an example
CharlesL: I think that for reading system it would be useful to skip examples
avneeshsingh: ok we can add in the comment
CharlesL: doc-cover... medium
avneeshsingh: I think it is fine.. any objection?
CharlesL: doc-dedication
avneeshsingh: there are edge-cases, but most of the type are identifiable
CharlesL: I think it is fine to keep medium
Naomi: yes, in most of non-fiction books you don't have it
Bill_Kasdorf: and normally you use the word "dedication" in the text e.g. this book is dedicated to my__
CharlesL: doc-epilogue... medium
avneeshsingh: any objection?
CharlesL: doc-foreword... medium
avneeshsingh: any objection?
CharlesL: doc-preface
avneeshsingh: same as doc-introduction?... medium
avneeshsingh: any objection?
CharlesL: doc-acknowledgments
avneeshsingh: It can be medium
Bill_Kasdorf: from a point of view of end users, acknowledgments normally are not expected to be read
Naomi: yes, sometimes they are very long: 4-5 pages
CharlesL: doc-afterword
Naomi: I would move it to medium... in non-fiction books they are normally appended some years after the publication
CharlesL: doc-colophon... medium
avneeshsingh: any objection?
CharlesL: doc-credit and doc-credits
Bill_Kasdorf: are similar to acknowledgements
Naomi: I think it is different, it is relative to copyright staff... but are not for end users. It can remain as low importance for end users.
CharlesL: doc-epigraph... low
avneeshsingh: any objection?
CharlesL: doc-errata... low
avneeshsingh: any objections?
CharlesL: what is an errata?
Naomi: a quote at the top of a chapter
CharlesL: why not moving to medium?
Naomi: it is quite simple to understand it without roles: it is a quote right after the heading
Bill_Kasdorf: what about doc-cover as low, since we already have "cover" in the alt-text
avneeshsingh: yes, but in a webpage or in a website it is important where cover may be placed on a big web page with the text of web page below it.
Bill_Kasdorf: ok for keeping it as medium for these use cases
avneeshsingh: We have completed the list. Next steps? I will send out this list to Publishing CG for one week review, so that group members not available in today's call are able to comment. Then we need to group these roles for presenting them to ARIA WG. Charles, Gregorio, Matt, George and Avneesh can work on the grouping for more appealing presentation.
avneeshsingh: We also need to find out appropriate time for having regular Accessibility task force calls for Publishing CG as the load of EPUB 3 WG accessibility calls has reduced.
Present: Alex_Grover__, avneeshsingh, Bill_Kasdorf, GeorgeK__, gpellegrino, laurent_, mgarrish, Naomi, tzviya, zheng_xu, Madeleine, Pascal Calarco
Chair: avneeshsingh
Scribe: zheng_xu
Topic: Which are the more frequently used DPUB ARIA roles?
Avneeshsingh: main issue: https://github.com/w3c/aria/issues/1643
avneeshsingh hand over to mgarrish to the first agenda
mgarrish basically it was raised in Aria about a number of issues related to Aria module … the dpub aria is to trying to improve dpub aria better than put role into aria … we can document better to help understand ARIA Authoring Practices Guide … there are about 37 roles but what is the most important roles for us to document … for this meeting, it's basically to narrow the larger roles to smaller list
Avneeshsingh: one thing we wanted to notice is chrome including playbooks has large improvement on DPUB-aria support … the main objective of this meeting is to prioritize a set of DPUB ARIA roles which can be included in ARIA authoring practices.
tzviya I think Apple is aligned in making books more accessible. and want to conform with technology such as JAWS and other
GeorgeK my concern is once WebKit implement some of it, it may deprecate others.
Tzviya: I think Apple is not refusing to implement it but their concern is that the Chrome implementation might be too much information overload for the users.
Avneeshsingh: The principle of ARIA that Rich and Joanie told us was that it is user agent’s responsibility to expose ARIA, it is up to AT to decide what to speak and how much to speak. ARIA WG do not mandate what to speak and how much to speak. Therefore information overload has to be handled by the AT.
GeorgeK: Different people have different requirements. Screen readers provide verbosity settings to address it, it gives you option to choose how much formatting, punctuation or semantic information you want to hear. In W3C we have super tech users. they process information differently from normal people. how can we satisfy both needs
Avneeshsingh: https://docs.google.com/spreadsheets/d/1atUkcAbkHpS5eUJ1rdDCrQ3saY8HZEMTNtWkanASLo4/edit?usp=sharing
Avneeshsingh: A subset of us came together and prioritized these DPUB roles to provide a starting point for today’s discussion. Interesting thing is that we ended up with more than half in critical + high importance. How can we narrow down further. We followed the principle that actionable roles should be of highest importance.
tzviya: I think it's how we could sell this list to ARIA WG. Maybe we can group some of them but not suggest to remove yet. Suggest not start with importance of list items
Avneeshsingh: Yes, it is a good way to present it to ARIA WG. Should we go through high priority items one by one?
CharlesL starting with items from top … most of items are Structural … doc-toc is the highest one obviously
mgarrish just needed some clarification … is there any policy to define Critical, High and other level … so we could use the criteria
CharlesL there is a lot of epubs that publisher is putting in. So we needed this to be clear that publisher could label book correctly … might need more publishers to help answer this
GeorgeK there seems to be some items that is only used by publisher but not in other industry … such as doc-index and some of others
Bill_Kasdorf some of the items are related to publisher's workflow … one thing is once it's published for example some section will always have the same header such as "Abstract", "Appendix" … how we could help reader to understand that
CharlesL answering Paul's question. Good questions, Benetech and Daisy might need to survey end users
avneeshsingh there is an issue that W3C does not really connect to end users and community is doing that … can we look at the list from end user perspective as well?
pascal I think some of the items might also impact to end user a lot … the title of the section from end user perspective is to use it to determine if I should read the section. … I also think we could probably find end users through some organizations
tzviya footnote and other types of notes might get higher priority but I understand it's not a lot books having hundreds of notes
GeorgeK the critical items I think are some of these are blocking user from reading the book … for example so many notes that user cannot read the book … if any marks could help end user understand that then they can at least read the book … so, if any items could help user to read the book then should be critical … or for example page number might be very noisy for end user as well … since it was read aloud each page
mgarrish when I look at the list I am thinking if any items one step below Critical it should be great help user to read the book … for example bibliography maybe should be Medium
CharlesL let's review critical items
… doc-backlink, any objection to have it in Critical?
(no)
… next biblioref, good
… glossref, good
… doc-index
index, bibliography and appendix suggest to move to Medium
next doc-noteref, keep
next pagebreak and pagelist, keep
GeorgeK does pagelist has to be a list of 1 to 800?
CharlesL next doc-chapter
should it be high?… I think could be Critical?
tzviya if we don't consider it as Critical then we should leave a note there
gpellegrino we usually split chapter to a different html file … I think it's probably high or medium
GeorgeK I can see publishers might use a separate file for "chapter" … I think it should keep as high
doc-conclusion move to Medium?
CharlesL doc-conclusion move to Medium. all agree
… next doc-endnotes
GeorgeK I recommend to keep it as high
CharlesL do we tie doc-endnotes to doc-chapter?
Naomi endnotes is still a bit different from chapter
CharlesL move endnotes to Critical
… next, doc-example … it depends on what kind of book structure we have
Naomi it could be a blocker for user to read the book … is it critical to say some items might be content specific item to be critical since it might be blocked in some type of books?
CharlesL doc-example move to Medium
Avneeshsingh: We are coming to end of the call. Should we assemble again next week for this list? … let's have one more week of discussion on this. Let us meet again on Thursday, 3, 2022, at 16 UTC.
Topic: Overview of the feedback received by EDRLab, France for User experience guide for accessibility metadata
laurent_ for the a11y of epubs on each books, EDRLab we have a session of workshop coming soon … we presented some a11y guides to publishers such as onix and stuff … and we asked for feedback … one feedback is since the guide are provided by group of expert so when we put it to large audience they might not have much idea of certain items … so we did some proposal of different profile regarding to a11y for example certain profile for certain user group … there is also needs for search items … search accessibility contents
Avneeshsingh: bottom line is once we got this priority of DPUB ARIA roles done, we need to come back to user experience guide and guidance for writing accessibility summary. So, very interesting work ahead. Thank you very much for the feedback
… meet you all next week at the same time
Original raw minutes: https://www.w3.org/2022/01/27-pcg-a11y-minutes.html
(Meeting at Japan/Australia friendly time)
Present:Avneesh Singh, Jens Tröger, Charles_L
Welcome to Jens Tröger, Bookalope
Avneeshsingh: There are only three of us in the call. How should we take it forward. Should Charles and I brief Jens about the discussions that we had in our planning call on November 30?
jens: I have gone through the minutes sent by you.
Charles_l: That’s great, so may be you can provide us the feedback and inputs.
Jens: I do not have much to say. All looks good. Right now I am following up the work of the group, and would like to contribute also. In my company I am working on improving EPUBs by using AI. So, if you think that my experience can be useful in some work in the group, please inform me. I have been listening to these calls and also EPUB 3 calls.
Charles_l: There are multiple groups for publishing in W3C. Sometimes it becomes confusing which work belongs to which group. Avneesh usually makes the judgement for accessibility work. May be we can explain the work of different groups.
Avneeshsingh: Yes, so many groups make it confusing. Lets start from EPUB 3 WG. It is a working group for EPUB 3.3 specifications. This group produces the W3C Recommendations, and the participation is limited to the full members of W3C. Which also means that broad community may not be able to participate in all the meetings. The work which is specific to EPUB 3 goes to EPUB 3 WG, provided it is concrete and is not a work at incubation level. Then there is Publishing CG, where we can do the work related to publishing in general, it may be for Audio Books, Web Publications, EPUB 3 or some other formats. Since it is a community group, full membership of W3C is not required, which also provides opportunity of broader participation from publishing industry, for example the User experience guide for displaying metadata is independent of publishing formats, so we are doing it in Publishing CG. If you have an idea that you would like to incubate, Publishing CG is the group for it. Then we have created another group named as ACCESSIBILITY DISCOVERABILITY VOCABULARY FOR SCHEMA.ORG. This group has very specific objective to maintain and update the metadata values for schema.org accessibility metadata. The schema.org accessibility metadata has broader scope than publishing, so instead of boxing it in publishing groups, we have created a separate community group for it.
Charles_l: Our work happens in the accessibility task force of EPUB 3 WG, Publishing CG and in the new schema.org accessibility metadata CG.
Avneeshsingh: That’s not all, I should also mention couple of more groups. There is a publishing business group where business managers and production managers are interacting, but it also have technical people. And then there is a Publishing steering committee where chairs of all these groups come together for coordination.
jens: Thanks for this overview. I think I would like to participate in the technical groups.
Avneeshsingh: Anything else to discuss for now. If not, then we can end the call, and meet again in January 2022.
Present: Alex_, avneeshsingh, CharlesL, George, gpellegrino, JF, Madeleine, mgarrish, rickj
Welcome to new participants: Alex Grover (Penguin Random House), Pascal Calarco (University of Windsor), Raja Deiveegan (Apex CoVantage)
Chair: avneeshsingh
Scribe: gpellegrino
avneeshsingh: welcome to Publishing CG a11y TF … the idea is to define an agenda for the next months … let's start from today's agenda
Topic: Guidance for writing accessibility summary
(Raw document for starting point is at:https://github.com/benetech/AccessibilitySummaryEPUBMetadata/blob/master/AccessibilitySummaryAuthoringGuidelines.md)
avneeshsingh: Guidance document for Accessibility Summary. it's a metadata for humans (non-machine-readable) … publishers are asking for guidance on how to create good accessibility summary
George: we started with this guide at the same time of the UX guidelines for displaying metadata … the UX guide was more urgent, so we focused on it
gpellegrino: what's the status of the document?
avneeshsingh: it is an early draft
JF: will it be published as a W3C note?
avneeshsingh: it should be published as a Community Group note
JF: I suggest to investigate in publishing as a EPUB WG note
avneeshsingh: Accessibility summary metadata is not specific to EPUB 3, Audio Books, WP and other publishing specifications can use it, this is why we would not like to box it in EPUB 3.
avneeshsingh: … CharlesL, can you move the document in ReSpec?
CharlesL: yes, if mgarrish can help with the first transformation
mgarrish: I can setup the document and respec.
Madeleine: does this will enable issue tracking for this doc?
avneeshsingh: yes
CharlesL: accessibilitySummary is only text, we cannot have formatting there
rickj: I think this could be useful also for other formats (like PDFs)
avneeshsingh: Yes, it is independent of publishing formats.
Topic: maintenance of the UX guide for metadata
https://www.w3.org/publishing/a11y/UX-Guide-metadata/principles/
avneeshsingh: there are some changes in the new EPUB Accessibility 1.1 specs, so we have to update Ux guide accordingly. Gregorio and I also had a call with EDRLab on their work in France
gpellegrino: they're setting up a working group for displaying accessibility metadata of ebooks, really similar to our work … this work was requested by the French Ministry for Culture … they've set up a working group with publishers, librarians, ecommerce and end-users
gpellegrino: they've translated the UX guide in French … and they've developed a mockup for displaying metadata … they'll test it with end users and give us feedback
Madeleine: https://github.com/w3c/publ-a11y/issues
rickj: I think it may be important to find a solution for accessibility metadata reconciliation (from different sources) … the problem is if they're conflicting
gpellegrino: I think we can work on it in this TF, producing best practices
avneeshsingh: Additional thing, for maintaining the Schema.org values we've created a specific community group led by Matt, Charles and Madeleine
mgarrish https://www.w3.org/community/a11y-discov-vocab/
https://www.w3.org/community/a11y-discov-vocab/
CharlesL: we have a wiki page with the different values for EPUB accessibility … we have to clean them; some examples are outdated
Madeleine: for now the group will work more on issues and posting rather than with meetings
Topic: Document for explaining difference between audio books, audio sync with text and read aloud
https://github.com/w3c/publ-a11y/blob/main/editorial-drafts/audio-playback/index.html
avneeshsingh: people were confused on the difference between audiobooks, TTS, MO, etc. … The document is nearly finished, I think in the next meeting we can vote for publish it
mgarrish https://w3c.github.io/publ-a11y/editorial-drafts/audio-playback/
avneeshsingh: as a CG report. Please review it before our January 2022 call, and then we will ask for approval.
Topic: Should we move ARIA roles and EPUB:type guide from IDPF to W3C?
https://idpf.github.io/epub-guides/epub-aria-authoring/
mgarrish: we have some IDPF documents that weren't re-published as W3C … the only document that is related to accessibility is the mapping between epub:type and DPUB Aria roles … it needs some updates … the question is: should we republish it under W3C?
gpellegrino: I think it is important to update and re-publish it
George: I'm a little bit concerned of too many documents... maybe we can add it to the DPUB Aria specs
mgarrish: this is very much related to EPUB
avneeshsingh: is a Community Report the right type of document? Since epub:type is specific to EPUB 3, it should be a WG note in EPUB 3 WG.
mgarrish: yes, maybe it is something that may be transferred to the EPUB WG
CharlesL: I don't even know if it is an "accessibility" document
mgarrish: I'll open an issue in the EPUB WG for moving this document
CharlesL: with the CG we have a broader audience, but the document is done, so we only have to update and publish it
mgarrish: yes, when published everyone can give feedback, it is open
avneeshsingh: Nothing stops us from discussing a EPUB 3 WG note in this group, to seek wider feedback.
rickj: If something is specific to EPUB 3, then it goes to EPUB 3 WG, but if something is more generic to publishing then it is in Publishing CG. Is this how we decide?
avneeshsingh: Yes, this is how we are doing it most of the time.
JF: +1 to Rick
JF: which is why I asked about making the accessibility statement document an actual w3c Note
Topic: Further discussion
avneeshsingh: are other tasks on which members want to work on?
George: what about MARC technique for UX guide?
pascal: We have a metadata group in the library focused in accessibility … we have some contacts in IFLA
avneeshsingh: great!
George: maybe we can open an issue on that
CharlesL: there is a grant for libraries for developing accessibility metadata, training, etc.
avneeshsingh: Since the load of accessibility work in EPUB 3 WG is reducing, I am hopeful that there will be regular calls of this group from beginning of next year.
… thank you all for this co-planning of the next 7-8 months!
Original raw minutes:
https://www.w3.org/2021/11/30-pcg-a11y-minutes.html
Present: Avneesh, Gregorio, John Folio, Madeleine, Charles and George.
Chair: Avneesh
Scribe: Gregorio.
Topic 1: Finalize User experience guide for accessibility metadata: version 1.0 release.
avneeshsingh https://w3c.github.io/publ-a11y/UX-Guide-Metadata/principles/
avneeshsingh https://github.com/w3c/publ-a11y/issues
avneeshsingh: we fixed all issues for this release, there are others which requires more discussion we leave them for next release
gpellegrino: we have to merge the branch for images … then I have to fix small errors on internal links and then we are ready from a formal point of view
CharlesL: right
JF: I don't know if it is the right call, I have concern about the conformsTo metadata (and the issue that Avneesh raised about the tolerance)
avneeshsingh: this document is about interpreting and displaying metadata, not on the metadata itself
JF: I understand, but if I have a badge on the page telling that the ebook is conformant to WCAG and then it is not...
avneeshsingh: I think it is out-of-scope for this document
JF: maybe we can add a note near conformsTo telling that there is an open issue
avneeshsingh: what do all of you think?
Madeleine: I think that since there is a certifier we shouldn't have problems. Such inaccurate claims can be an issue for many metadata values, not just conformsto. Should why should we do something special for conformsto.
CharlesL: maybe we can add a note telling that conformsTo may change in the future
JF https://w3c.github.io/publ-a11y/UX-Guide-Metadata/principles/#example-1
George: I think that publishers can put something about the level of conformance in the accessibility summary
JF: I pasted example 1, this example tells me that this book is fully compliant
gpellegrino: I think the metadata is correct, the ebook in the example is fully conformant
avneeshsingh: maybe having a generic note is fine. It can state that the document will be updated as the accessibility metadata will evolve.
JF +1 to generic Editor's Note
CharlesL: also this points to EPUB Accessibility 1.0, not 1.1 where we have relaxed the requirement for long descriptions
avneeshsingh: ok, what about having a note?
Gpellegrino: +1 to note
JF: may we add an example of an accessibilitySummary telling that the ebook is not fully compliant?
George: This is a live document, we can update it after some time.
Avneeshsingh: Once EPUB Accessibility 1.1 goes to CR, near end of this year, we will need to update this document anyways.
avneeshsingh proposal: release version 1.0 of user experience guide with editor's note that doc will be updated with update in metadata
Gpellegrino: +1
JF +1 to adding a note
CharlesL +1
Madeleine +1
CharlesL George +1
avneeshsingh resolved
CharlesL: where do we want to put the note?
gpellegrino: in the Principles
CharlesL: maybe also in the EPUB techniques metadata. Another thing, I would be too busy in coming days, would Gregorio like to take over adding this note?
gpellegrino: Yes, I can do it.
avneeshsingh: ok, we can put in techniques also.
CharlesL: I wonder how this issue of conformance can be addressed in ONIX. Good luck for that.
Avneeshsingh: This is why we need a thorough discussion on this topic.
Topic 2: Planning for the release and promotion.
avneeshsingh: maybe we can release early and promote after one-two weeks
gpellegrino: I can work on this document this week
George: what about on the 7th the release … and September 21st for launching the communication
avneeshsingh proposed: release on sept 7, and start promotion on sept 21
egrino: +1
CharlesL: +1
Madeleine: +1
CharlesL: this will be a CG report, correct? … do we need checks with the Community Group?
avneeshsingh: no, we discussed it in CG call, and chaires made it clear that the decision making in publishing CG is de-centralized. Accessibility task force can go ahead when satisfied.
Avneeshsingh: resolved
Topic 3: communication
Avneeshsingh: … we will need both internal and external … the target is mainly distributor, retailers and librarians … in W3C we'll announce in Publishing CG, EPUB 3 WG, Publishing Business Group and Publishing Steering Committee … do you think other groups are interested?
George: I can tell about it in the chairs' call
avneeshsingh: what about outside W3C?
Madeleine: IMS Global and the libraries in Canada
George: also Bennetech is really interested, Cristina in LIA and in DAISY Sarah and Richard
… I have an IMS Global meeting tomorrow, I can tell them
avneeshsingh: why not organize a call with people outside W3C?
egrino: +1
CharlesL: what about retailers that would implement them?
George: they are target audience, but they wouldn't help with the communication
avneeshsingh: George and I can take up responsibility of compiling the list of people outside W3C with whom we would like to engage and organize the call with them.
avneeshsingh: Thank you.
Original raw minutes:
https://www.w3.org/2021/08/23-pcg-a11y-minutes.html
Present: AlexGrover, avneeshsingh, CharlesL, George, gpellegrino, laurent_, MadeleineRothberg
Chair: Avneesh Singh
Scribe: Gregorio Pellegrino
Meeting minutes
Avneeshsingh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/principles/
Avneeshsingh: https://github.com/w3c/publ-a11y/issues/32
Avneeshsingh: removing specific mentions to formats in the principles We should make more generic "EPUB" and "ONIX" in the principles document
George: may we have "accessibility metadata" instead of only "metadata"?
avneeshsingh: do we approve it?
George +1
laurent_ +1
Gpellegrino: +1
Avneeshsingh: approved #32 with modification of accessibility metadata instead of metadata
Avneeshsingh: https://github.com/w3c/publ-a11y/issues/28
Avneeshsingh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/principles/#ui-technical-details
avneeshsingh: The focus of the guidelines is to mainly address accessibility metadata, not generic metadata and this is an example about generic metadata. … so section 3 is more for examples
MadeleineRothberg_: I think the issue is it ok to have "audiobook" in the front, instead that inside the "metadata" section?
gpellegrino: I think that it is only an example … so we can clarify it
avneeshsingh: proposal: provide a clarification that this is an example
MadeleineRothberg_ +1
gpellegrino+1
George: +1+1
Mgarrish: 0
laurent_: 0
Avneeshsingh: resolved
Avneeshsingh: https://github.com/w3c/publ-a11y/issues/33
avneeshsingh: right now conformance URL points to IDPF. We are updating the URLs in EPUB Accessibility 1.1, but the fact is that we will publish that document in 2022, and we should not point to specification revision which is in early stages.
mgarrish: actually they do not point to pages, but they are URIs … so we can change the note from "they point to an IDPF page" to "they point to an IDPF URIs"
avneeshsingh: Matt, can you add it to the issue tracker?
RESOLUTION: agreed with approach mentioned in issue tracker, and Matt will do minor improvements
gpellegrino: may we not close the issue and tag it for the next version?
avneeshsingh: good idea.
avneeshsingh: https://github.com/w3c/publ-a11y/issues/30
avneeshsingh: https://github.com/w3c/publ-a11y/issues/29
avneeshsingh: these two are straight forward
avneeshsingh: Proposal: approve #30, #29
gpellegrino: +2
MadeleineRothberg: +1 George +2
Avneeshsingh: resolved
Avneeshsingh: https://github.com/w3c/publ-a11y/issues/34
Avneeshsingh: https://github.com/edrlab/thorium-reader/issues/1332#issuecomment-763486512
avneeshsingh: the next issue it is only for techniques, so it is not compulsory to solve it now
avneeshsingh: the basic question is: is an audiobook a publication of only audio? Or also a Media Overlay EPUB is an audiobook?
charles: for me if it has audio it is an audiobook
laurent_: I agree with Charles, but from a user point of view the user interface to access the content is different
George: there are a lot of features that are available in EPUB MO and not in audiobooks (for example searching, highlight), so we have to display the difference
laurent_: maybe we can only change the label "audiobook"
avneeshsingh: I'm concerned about changing the label now at last stage, we have to move forward the publication of the document
laurent_: I agree with Avneesh
George: do we need something like "multimedia overlay"?
avneeshsingh: right now we have that if access-sufficient = audio, than it is an audiobook, which means even if AccessModeSufficient = auditory, textual accompanies it, then also it is marked as audio book.
George: I think it is a marketing stuff to describe a publication as purely audio or audio+text
gpellegrino: for only text we have "screenreader friendly", "audiobook" is a type of publication, not a way to access the content
mgarrish: is it a metadata problem or is it a wording problem? … maybe we can say "audio playback" available
laurent_: Frankly "Audio Playback" would be better than "Audiobook" here
MadeleineRothberg_: I think the problem isn't in the metadata, I think it is more on the label side … maybe we can use "Full audio available" … maybe we can use a note, but we can also change the label
George: I think we should add examples about this
avneeshsingh: what is the cost of delaying the publication of 1-2 weeks for changing the label? Audio book has a different public perception, after this discussion I am feeling that it is difficult to fix this without fixing the label.
Laurent_:Example https://w3c.github.io/publ-a11y/UX-Guide-Metadata/techniques/epub-metadata.html#example-9.1-all-metadata-fields-present presents what an EPUB 3 with Media Overlays will get
gpellegrino: may we vote?
avneeshsingh: Proposal: delay publication a little and correct label for audio books
gpellegrino: +1
MadeleineRothberg_: +1
Mgarrish: +1
laurent_: +1
CharlesL: +1
George: +1
avneeshsingh resolved
avneeshsingh: Madeleine maybe you are the right person to find a new wording
laurent_: we can add an example of metadata for EPUB MO as shown here: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/techniques/epub-metadata.html#example-9.1-all-metadata-fields-present
… I will open an issue on this
avneeshsingh: do we want to brainstorm now for the right label for audio?
laurent_: what about full audio?
MadeleineRothberg_ +1 to full audio
CharlesL: +1
CharlesL: if it has access-mode sufficient textual we will have "screenreader friendly", maybe also having "full text" we'll also be fine
MadeleineRothberg_: for audio it is simpler: we have only one metadata
avneeshsingh: Volunteer for editing the guidelines as per our decisions today?
gpellegrino: me!
CharlesL Yes I can help on the EPUB schema techniques
avneeshsingh: any other stuff?
George: what is our timeline?
avneeshsingh: I think in a week we can have the editorial stuff done
CharlesL: are we planning to add new examples for "full audio"?
George: maybe we should also have "synchronized text-audio"
avneeshsingh: we can do it in the next version
MadeleineRothberg_: we are only suggesting what to put in the UI, we don't have to list all the different possible combinations … if providers want to say something more or something different, it is fine"
mgarrish: We have the information for EPUB MO in the metadata (under accessibility features)
CharlesL: in our document we have 4.2 section "Audiobook" … we have to change also the definition
MadeleineRothberg_: Charles you're right, because right now we are only speaking about audiobooks and not about EPUB MOs
avneeshsingh: I think this is a fundamental thing, in this way we don't focus on content type, but on accessibility features
George: are we opening a new category for synchronized audio and text?
avneeshsingh: not right now, we do not want to get into endless cycles of improvements, and pushing the release date further and further.
avneeshsingh: thank you all!
Original raw minutes:
https://www.w3.org/2021/02/05-pcg-a11y-minutes.html
Present: Avneesh, gpellegrino, AlexGrover, George, CharlesL, LauraB, mgarrish, zhengxu, lucaudrain, Bill_Kasdorf, Makoto, Madeleine.
Chair: Avneesh
Scribe: gpellegrino
Avneesh: before user experience guide for accessibility metadata, there is another discussion raised by Makoto. It is for metadata for Ruby, we discussed it a little in 2016, when EPUB 3 was under IDPF.
Makoto: topic a11y metadata for ruby characters ... I'm Chair of DAISY Japan technical committee; we have been discussing a11y metadata for the Japanese language ... one is ruby, another is horizontal or vertical writing, last one is on adding space between words ... the first document is about requirements for the discoverability of EPUBs containing ruby ... we need both ONIX and Schema.org metadata for consistency
Mokoto: VIPs really like ruby both general ruby and parallel ruby ... Since para-ruby is so common in Japanese textbooks ... Some users are very annoyed by ruby (e.g. dyslexic people) ... an easy solution is to not display ruby ... some users don't care (e.g. partially sighted users) are ok with ruby ... so we need different status: no-ruby, ok with ruby, ...
CharlesL: accessibilityFeature="rubyAnnotations" is currently available. Idea is to add more
Mokoto: we're working on requirements docs, after that will propose metadata for Schema.org and ONIX
mgarrish: we already have "ruby-notation" in Schema.org, is it enough?
Makoto: we are discussing it, maybe we need more values
Avneesh: Makoto you can send out the proposal for metadata when it is ready.
... next topic: ONIX feedback on UX metadata guidelines
Avneesh: I am providing the links to some issues which are straight forward, these were in agenda, you may have already gone through these links. I had summarized the conclusions in the issue tracker. If there are no objections to these, we can approve them collectively.
Avneesh: https://github.com/w3c/publ-a11y/issues/23
Avneesh: https://github.com/w3c/publ-a11y/issues/22
Avneesh: https://github.com/w3c/publ-a11y/issues/21
Avneesh: https://github.com/w3c/publ-a11y/issues/17
Avneesh: https://github.com/w3c/publ-a11y/issues/15
Avneesh: brief overview #23 hazards, they have provided codes for different hazards ... #22: certified by for displaying the certifier
gpellegrino: I'm not sure we have "no hazards" in ONIX
Avneesh: there are different codes "no flashing", "no sound", ...
CharlesL: do we have to do the same for Schema.org? Telling "no flashing", "no sound hazard"... ... maybe we can list both options in the crosswalk
MadeleineRothberg: yes, it is a roundtrip ability issue ... we could put a warning for now.
Makoto: I support round-trip conversion.
Avneesh: if we want to have a code for "none" in ONIX we need request it and it takes some months. Today, lets decide what we should do at current state. I think we can add existing hazards in ONIX to technique document with the warning that Madeleine mentioned.
CharlesL: issue 22, I didn't realize we can have multiple certifiers
mgarrish: I think the issue is on how ONIX can manage this field ... I think we can make more specific in next EPUB version
Avneesh: this discussion for EPUB Accessibility have to happen in the Working Group ... I think that before asking ONIX we have to improve it in EPUB specs, then we can ask ONIX for adding these fields
George: what is the goal here? Do we need multiple certifiers or do we want it to be unique? ... maybe it depends from the jurisdiction
CharlesL: I thought about it a lot, since publishers are improving their processes this may make sense ... from a library o bookstore prospective it is difficult to understand which one to show
lucaudrain: I agree we should define EPUB accessibility specs before ONIX ... the publishing industry in France will self-certify their publications
Avneesh: In today’s call our focus is on the ONIX code which are available and update the documents accordingly. We can definitely discuss further list of codes to propose in upcoming calls. Up to now we have not heard any objections to conclusions of #23, #22, #21, #17 and #15. So, finally, any objections for adding these issues to ONIX techniques? ... no!
CharlesL: We can do +1 in favor of adding or -1.
Makoto +1
CharlesL +1
lucaudrain +1
MadeleineRothberg +1
Bill_Kasdorf +1
mgarrish +1
Avneesh +1
LauraB +1
George +1
Avneesh: All approved. Now lets move to issues which may require some discussions.
Avneesh: https://github.com/w3c/publ-a11y/issues/20
Avneesh: it looks simple
gpellegrino: ok for me!
CharlesL: onix feed is a group of records, so fine
Avneesh: ok, we can approve it
Avneesh: https://github.com/w3c/publ-a11y/issues/19
MadeleineRothberg: I added a propose with edit to merge last sentences ... maybe we have to check it with EditEUR
mgarrish: a think we have to change first sentence "EPUB or Schema.org" since EPUB doesn't have a11y metadata
https://w3c.github.io/publ-a11y/UX-Guide-Metadata/techniques/epub-metadata.html
gpellegrino: we have discussed for naming it "EPUB Accessibility metadata", may we name it?
CharlesL: I think it is a good idea
CharlesL: maybe in the future we can move this metadata from EPUB to Schema.org (in long-term)
Avneesh: for now I think we need a link to explain people what do we mean by "EPUB Accessibility Metadata" ... is it ok to link to the techniques? Or to the vocabulary page?
mgarrish: I'm not sure, maybe we can link to accessibility metadata
MadeleineRothberg: I'm not sure we can move all metadata to Schema.org, for political issues
Avneesh: I agree, maybe we don't need everything in Schema.org
mgarrish: Yes, I think it is something we have to discuss while writing specs, in the future
Avneesh: the recommendation is to link to metadata in EPUB accessibility specifications and Matt will write a new text for ONIX people to review.
Avneesh: https://github.com/w3c/publ-a11y/issues/18
Gpellegrino +1
lucaudrain +1
CharlesL +1
Avneesh +1
LauraB +1
MadeleineRothberg +1
jens +1
Bill_Kasdorf +1
George: I think the existing software that moves metadata from ONIX to MARC ... but MARC is based on Schema.org
George +1
Avneesh https://github.com/w3c/publ-a11y/issues/16
George: so it's a round-trip issue, but we don't have to manage it now
CharlesL: I'm trying to understand what is the proposal
Avneesh: It is for the definition of conformsto in the principle document. The definitions in principles document should be abstract, and then we go into specifics in techniques documents(ONIX and schema.org). But the text that George wrote in principles document was greatly tied to double core conformsto metadata, and gets into conformance links and other specifics. So I made it more generic
gpellegrino +1
MadeleineRothberg +1
Bill_Kasdorf +1
jens +1
CharlesL +1
George +1
Avneesh: next topic: editing
gpellegrino: I can do it..I won it!
Avneesh: Matt will add the text in the issue tracker ... do we need another call? In two weeks?
Avneesh: maybe we don't need it
George: when the documents will be updated, we can review it
lucaudrain: when we will send it for review we can make it public ... then may I refer to it as "public"?
Avneesh: yes!
Avneesh: What should be timeline for updating ONIX techniques document and conformsto definition in principles document?
Gpellegrino: 2 weeks. One dependency is to send note to ONIX people to review.
Avneesh: 2 weeks is good timeline. Thank you very much for a productive call.
Summary of Action Items:
- Gregorio: Update the ONIX techniques and conformsto definition in principles document in next two weeks.
- Matt: Add proposed text to issue #19.
Original raw minutes:
https://www.w3.org/2020/11/06-pcg-a11y-minutes.html
Present: Avneesh, gpellegrino, Bill_Kasdorf, AlexGrover, Naomi,CharlesL, George, Madeleine
Chair: Avneesh
Scribe: gpellegrino
Avneesh: Madeleine, are there updates from ONIX side?
Madeleine: I have to check, I can check with Gregorio
Gregorio: me too, I can help
Madeleine: we can contact EditEUR and check
Avneesh: Lets focus on the principles document. Do we need the landing page? Or the principle page is enough to act as landing page? ... The links for techniques can be on the principles page.
George: I agree
CharlesL: maybe we should simply add the information in the principle document
Gregorio: we decided to maintain documents independent from each other.
Avneesh: it is not specification, so we would have no problems updating. Even if it is a specification, informative sections can be updated easily, by errata.
CharlesL: would it be a note?
Avneesh: Yes, a CG note
Madeleine: would it be possible to add a link to the techniques index and say "at the time of this document the available techniques for metadata standards are..."
George: yes, and maybe add items for consideration for future work
Avneesh: we may have an issue tracker for future works
Madeleine: from an UI it is not simple to understand which are links and which are static text
Gregorio: I will check.
CharlesL: in the title we do not say "Principles document", maybe we can add it for consistency
Madeleine: we may edit all the titles to make them consistent
Bill_Kasdorf: +1 to Madeleine
George: maybe I disagree: the highest level document should be the principles of user experience guide, we may not need to explicitly say "principles".
Madeleine: In techniques documents, it mentions technique in document, maybe we can use “Guide" instead of "Principles" and define in the introduction that these are the principles.
Avneesh: Yes. Other improvements? I have a list of items.
... Rename "Schema.org" techniques document as "EPUB accessibility metadata", issue#8
... In definition of conforms to, in the principles we should not jump directly to the links of conformance. The definition should be at abstract level. In dc:conformsto we have links but in ONIX codepage 196 we have codes. So, we should first give abstract description and then give examples of links or codes.
CharlesL: I agree, also we have"idpf.org"
Avneesh: I can open an issue and then we can refine the text.
George: also when we'll have the ISO name approved.
AlexGrover: I appreciate the document, I think that starting with principles makes a lot of sense instead of landing page with some links.
CharlesL: for "All accessibilityMetadata" I think it's a little bit weak, where are we going to show all the different possible values?
Avneesh: you are talking about values of Schema.org accessibility metadata, which is maintained on a wiki?
CharlesL: https://www.w3.org/wiki/WebSchemas/Accessibility
CharlesL: may we transform thiswiki page as a CG note? ... Maybe we can publish it as an APA note?
Avneesh: the question is: would it make it more difficult to edit this document? .. schema.org does not govern the values, they govern the properties. There is a reason for having string values which can be extended. ... The objective is to have light weight governance, in the APA group, we will get into a heavy process, and also restrict it to full members, which can participate in WG. ... I have another suggestion: in W3C we have CGs, which are free for participants, maybe we can create a new CG for maintaining these values. We can define the light weight approval process in the CG charter.
George: are no other groups working on Schema.org?
Madeleine: there should be a vocab-CG
George: are we starting a new CG outside publishing, with all the web as scope?
Avneesh: If we put it in any publishing group, it will create a perception that these values are specific to publishing. This is why we should keep it independent of publishing. This work is driven by mainly us, since 2014-15, so we can keep on driving it in a CG, and may be more people will join CG and participate.
CharlesL: yes, I think it is more general
Avneesh: we can define in the charter a process for editing the docs
Bill_Kasdorf: what if we ask toSchema.org?
Madeleine: they usually say they manage the properties, not the vocabularies
CharlesL: If we move values from existing place, we have to ask the people who started this page.
Madeleine: I think it's us, who started it.
George: APA does horizontal reviews. May be they will consider CG reviews in the future.
Madeleine: One Relevant page, not updated since 2013
https://www.w3.org/2013/04/vocabs/
Avneesh: Lets come back to main topic. If we are done with list of improvements, I would like to know if editors have time to improve the document in next month?
Gpellegrino: I can help in editing
Avneesh: Thanks to editors. We should try to release first iteration in early September.
Avneesh: Follow-up comment after the call. We should keep registries in our radar for maintaining schema.org accessibility values.
Summary of Action Items:
- Madeleine and Gregorio to check if our proposed codes are added in ONIX
- Editors to improve the documents as per our discussions.
- Avneesh to open issue for improving text of conformsto definition.
- Avneesh to come up with a suitable way to maintain accessibility values of schema.org
Original raw minutes are at: http://www.w3.org/2020/07/16-epub3cg-a11y-minutes.html
Present: Avneesh, laudrain, AlexGrover, George, gpellegrino, wendyreid, Naomi, Bill_Kasdorf, Madeleine
Chair: Avneesh
Scribe: George
Avneesh: This is a follow up call to resolve the issues which were left over in last week’s call.
Avneesh: https://github.com/w3c/publ-a11y/issues/9
Madeleine: going through 9. I have not gone into specific details in the statements. We could be more specific about which issues we are talking about, or we could leave it vague.
Avneesh: Broad statements are fine.
Madeleine: Proposes that the language changes, "Inside the EPUB package." ... I proposed a shorter paragraph about the mapping.
Bill_Kasdorf: +1 to Madeleine's update
Madeleine: read through the paragraph recommendation.
Gpellegrino: +1
Avneesh: There are no objections, approved.
Gpellegrino: I will make the changes and close the issue.
Avneesh: https://github.com/w3c/publ-a11y/issues/4
Avneesh: issue 4
Avneesh: example is Accessibility conformance: EPUB Accessibility, WCAG A
Luc: I like the two values, because it is more precise.
Gpellegrino: +1 to Luc
Bill_Kasdorf: +1
Avneesh: There are no objections, approved.
Gpellegrino: I will comment the issue with our thoughts. Then modify the document and close the issue.
Avneesh: https://github.com/w3c/publ-a11y/issues/11
Avneesh: This is new issue that I created for discussion related to Low Vision Friendly field. Should we have discussion now, or should we discuss it on Github.
Gpellegrino: Everyone interested in the issue is not in the call, so we can discuss it on Github.
Avneesh: OK, it would be also better for people outside this group to interact on Github.
Avneesh: Another issue related to low vision issue is: https://github.com/w3c/publ-a11y/issues/10
Avneesh: https://github.com/w3c/publ-a11y/issues/8
Avneesh: Issue 8: The original topic of issue was about name of schema.org technique document. The document has techniques for schema.org as well as EPUB specific accessibility metadata, so it should not be named schema.org techniques. But later on the discussion evolved to whether we should have separate documents for techniques for each metadata format, or should we combine all the techniques in one document. Let us to resolve the question of multiple techniques documents vs single document first because it is moving towards conclusion.
Gpellegrino: At first it was in one document. We then thought it should be split, because we could add other metadata standards. We also split it into principles and techniques. This way we would be able to update them independently.
Avneesh: One way is to maintain status quo, maintain separate document for each metadata format techniques, and other way is to restructure the techniques documents and combine them. One comment on issue tracker says that even if we combine documents, then also we need to maintain separate documents, and then pull the content from these documents to summary/details in one document.
Bill_Kasdorf: Most people only pay attention to the one they care about and so those won't go obsolete when a different one changes.
Avneesh: There are no objections to maintaining status quo i.e. separate documents for techniques of each metadata format. So, we have the decision.
Avneesh: Moving to other part of the issue, about the name, it currently says Schema.org, but it is a combination of EPUB and Schema.
Gpellegrino: What about EPUB package metadata.
Avneesh: In last call, most people objected to using package or embedded metadata.
George: I think the only objection was using the EPUB metadata to infer information about the accessibility... this was in the transformability conversation ... Most of the time people are going to grab the accessibility metadata we specify ... Not grabbing the reflow statement from the EPUB, if we had to replicate that, it would be better than looking at other metadata ... I thought the objection was about using the word "package"
Avneesh: Yes, schema.org metadata is not confined to package, it can also be used on webpage of the book.
Gpellegrino: +1!
Madeleine: What about EPUB Accessibility metadata?
Bill_Kasdorf: +1
Wendyreid: +1
Laudrain: +1
Avneesh: Let's put this in the issue tracker, and give people time, if they want to object.
Avneesh: Do we want to decide time of next call now, or should we work on issue tracker for some time and then come together on a call?
Many members: Lets work on issue tracker, and then decide time of the call.
Avneesh: OK, thank you everyone for today’s call.
Summary of Action Items
- Avneesh: add name of schema.org techniques document to the issue tracker.
- Gregorio: Update the status of issues for the issues that we have resolved today, and update the user experience guide accordingly.
Original raw minutes are at:
https://www.w3.org/2020/03/31-epub3cg-a11y-minutes.html
Present: Rachel Commerford, Luc Audrain, Avneesh Singh, Gregorio Pellegrino, Madeleine Rothberg, Bill Kasdorf, Matt Garrish, Charles LaPierre, George Kerscher
Regrets: Tzviya
Chair: Avneesh
Scribe: Madeleine_Rothberg
Avneesh: For reminder, we are working on these documents https://w3c.github.io/publ-a11y/UX-Guide-Metadata/
Topic: Future of the documents when EPUB 3 CG will be closed in the favour of Publishing CG.
Avneesh: Recently we had important decisions for consolidating publishing in W3C in less number of groups. One will be EPUB 3 working group, one will be publishing business group and one will be publishing community group. EPUB 3 CG will merge with Publishing CG. So, I had discussion with Ivan for possible options for our work.. When EPUB 3 CG will merge with Publishing CG, the EPUB 3 CG repository will be renamed and documents will be renamed automatically. The other option is to wrap up quickly before EPUB 3 CG goes away. Looking at our objectives, the work on harmonization of metadata formats will continue for a year or more. So, I do not think that we have option to wrap up quickly.
Laudrain: EPUB 3 CG will be renamed to Publishing CG. Participants of EPUB 3 CG will be automatically included in the new Publishing CG group.
George: Our work on metadata is far from over, we cannot rush and wrap up.
Avneesh: So, the group’s consensus is not to wrap up, instead we will go with the flow of merging EPUB 3 CG with Publishing CG.
Topic: Any issue in formatting the documents like other EPUB 3 CG documents
Avneesh: Gregorio was formatting the metadata guidance documents like EPUB 3 specifications documents. Gregorio would you like to discuss anything with the group?
Gregorio: There are three main docs plus index for 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: Thanks to Gregorio and Charles for editing the documents, and thanks to Matt for providing the support.
Topic: further improvements required on principles and techniques documents?
Avneesh: There are some important issues filed which will need significant discussions.
Avneesh: https://github.com/w3c/publ-a11y/issues/10
Avneesh: This is related to displayTransformability. Madeleine, would you like to introduce it.
Madeleine: issue is that our document 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
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
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: We should 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: We should avoid getting into details today. Consolidating the discussion, we should not add new properties to UI document immediately, I should open an issue for discussing “Low vision friendly” where we should figure out if this information can be pulled out from existing accessibility metadata, and if it is feasible to add it to UI document.
CharlesL: ACTION: Avneesh to add a new issue to explore Low Vision Friendly
Avneesh Next issue is about revision to the Note at the top of the Onix section
Avneesh: https://github.com/w3c/publ-a11y/issues/9
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 evolve.
Charles: 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.
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 text 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: So, madeleine should work on refinement of this text as per the discussions.
Madeleine: I have 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
Avneesh: We do not have time for the last issue. I would like to provide you the link of the issue, matt has a nice proposal in it. We can finalize it on issue tracker:
https://github.com/w3c/publ-a11y/issues/4
Avneesh: When should we have next call?
Luc: I will be there next week, then I will retire from Hachette and will join in personal capacity.
Bill_Kasdorf: Thanks for staying involved, Luc!!
Luc: I am retiring from Hachette, but I will still be a consultant on accessibility
Avneesh: Let us have the follow-up call next week at the same time (14 UTC) to resolve remaining issues.. The time for Europe may change due to daylight saving.
Thanks all!
Summary of Action Items
- ACTION: Avneesh to add a new issue to explore Low Vision Friendly
- ACTION: Madeleine to draft language for both techniques docs that distinguish book features from reading system features
Original raw minutes:
https://www.w3.org/2020/03/24-epub3cg-a11y-minutes.html
Present: Avneesh, Julian_Calderazi, tzviya, Naomi, laudrain, alexgrover, George, Bill_Kasdorf, Charles_L, MattG
Regrets: Gregorio
Chair: Avneesh
Scribe: Madeleine
Topic: further improvements required on principles and techniques documents.
Avneesh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/principles/
Avneesh: How's the document looking?
Laudrain: please add me to the reviewers
Avneesh: Yes
Avneesh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/techniques/
Avneesh: https://github.com/w3c/publ-a11y/issues/8
Laudrain: it isn't all schema techniques
Madeleine: Schema and more? Schema plus? It is useful to reference Schema.org or name recognition
Avneesh: Embedded metadata techniques? But it is good to have schema.org in the name
Bill: Techniques for displaying Schema.org and other standard accessibility metadata
Avneesh: too broad? ... Expect to keep separate docs for internal and external metadata
Charles: Internal with a11y, schema, and epub metadata
Tzviya: not internal vs external. Hope to have wider usage ... Prefer to have fewer documents, although I understand why we have schema techniques separate Master document that links all of them
Avneesh: linking is good ... schema.org is not complete and so we need dc:conformsTo and epub terms
CharlesL: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/techniques/
CharlesL: this link is the overarching techniques doc that links the others
Madeleine: be sure we promote the central techniques doc that links to all of them
Avneesh: It is useful for editor for each kind of metadata to have their own doc to edit
Madeleine: and easier for implementers to read their own examples without others mixed in
Mattg: if it is about package documents metadata, why not say that?
Madeleine: who is the audience and what will they find most recognizable or persuasive?
Tzviya: the ones added to schema are to enable the use of schema.org, so we could call it that
George: marketing and communications around this area need intro document to explain the principles. ... link to other techniques is good, but one thing to bookmark for finding again
Bill_Kasdorf: encourage publishers to put it right on their web site
Laudrain: Retailer needs to read ONIX doc. If getting EPUB, needs to understand to look in the package document
Laudrain: https://www.epagine.fr/list-53692/livres-numeriques-accessibles/
Laudrain: French retailer epagine is linking to accessible books. Using ONIX feed. ... will ask contact there to look at these documents and ask if it is clear. Should also localize to French, Italian, etc.
Tzviya: +1 to mattg
CharlesL: +1 as well
Mattg: Techniques for display of schema.org metadata, not techniques FOR schema.org metadata
laudrain: MARC will be transferred from national library, outside the book
CharlesL: or External: ONIX, External: MARC etc.
George: Name consistently.
Madeleine: Techniques for the display of schema.org and (others) accessibility metadata, Techniques for the display of ONIX accessibility metadata etc.
Avneesh: We have consensus on the approach suggested by Matt. We can come up with the name in issue tracker.
Avneesh: https://github.com/w3c/publ-a11y/issues/6
Charles: that isn't a w3c standard page
mattg: This is CG report so we do not need to do like W3C specs. Here is EPUB 3 CG report page that we did: https://www.w3.org/publishing/epub3/
Tzviya: agreed that we need to follow w3c style.
Mattg: can use a simpler style link this one for epub3
agree with Matt
Avneesh: Lets follow the CG report practices for the documents. Matt can help the editors where ever required.
Avneesh: https://github.com/w3c/publ-a11y/issues/4
Accessibility Conformance: EPUB Accessibility (WCAG AA)
CharlesL: +1
Laudrain: +1
Madeleine: that is the specific term for epub acc ... section 2.4 of the techniques doc is called "EPUB Acc Conformance" which shouldn't be the section title
Tzviya: People mostly have heard of WCAG and that's what they know best
Laudrin: publishers in epub production don't know wcag, but people building web sites know wcag better than epub
Tzviya: general publishing staff know wcag or 508 but not epub standard
CharlesL: So instead of:
2.4.1.2 UI
EPUB Accessibility Conformance: http://www.idpf.org/epub/a11y/accessibility-20170105.html#wcag-aa
CharlesL: we should have just:
Accessibility Conformance: http://www.idpf.org/epub/a11y/accessibility-20170105.html#wcag-aa
Avneesh: if wcag conforming: accessibility conformance: wcag aa
if epub conforming, dont' put wcag, just put epub accessibility.
Naomi: could it have two lines showing conformance to wcag and epub separately
George: wcag is a high level publication. it is abstract and applies to any kind of page or doc ... but I’ve never seen a pdf that claimed wcag conformance
Madeleine: are we discussing the section title for 2.4, or the contents of conformsTo statements, or the user-friendly UI for a given conformsTo statement?
Avneesh: how to make the UI less confusing for the statement. ... for now we have consensus to replace the heading EPUB Accessibility Conformance with Accessibility Conformance. And on issue tracker we can discuss and decide how to make values less confusing.
Topic: Further updates for collaboration with IFLA, for MARC metadata format.
Avneesh: ... This will be a slow process. ... Markku Leino from CELIA and Finland DAISY Consortium will be liaison and will join future calls. After 24 March, another person will be appointed
Madeleine: who created the crosswalk?
MURATA: Ando-san?
Avneesh: Japanese member. ... project plan is being prepared, and then a new liaison will be appointed
Laudrain: There are several MARC standards. There is UniMARC and MARC21 but I hope they will converge ... I am not in touch with IFLA people but would be happy to be
George: How big is that working group?
Avneesh: Not sure about exact numbers, may be 5 or 6. It will be more clear after March meeting
George: Lots of interest in Canada. Could they get involved?
Avneesh: I will follow up
Topic: Further update for discussions with Google for accessibility metadata search.
George: CharlesL and Gregorio and I met with Google staff. Kiran Kahja, couple others
CharlesL: they think this has value but they don't want to misrepresent what a reading system can do ... if some of the acc features aren't available on this reading system they would need to edit the presentation of metadata
George: inside play book environment, they want to expose acc metadata, but also in general search
Laudrain: play books receives metadata from publishers in ONIX. uses for prices and titles and so on ... keen to store acc metadata from onix, hope to use it so when users search for a book and get a knowledge card ... knowledge card has a module that links to where you can buy the book ... they could have a checkbox in the module to find the book where acc metadata is displayed, for example ... but if it is on those websites selling the book it is probably in schema.org!
Bill_Kasdorf>: It's the Crossref Books Advisory Group
Madeleine: you can use acc metadata to describe the features of the reading system so that you can automatically know how to filter metadata ... Is it OK if Bill K and I present these docs as work in progress to the Crossref books advisory group?
Avneesh: yes, but emphasize work in progress
Topic: Next meeting:
Avneesh: next meeting March 6? ... I will do a doodle poll to see if this works for everyone. In March there are many events, CSUN, London book fair, ebook craft, etc.
Original raw minutes are at:
https://www.w3.org/2020/02/14-epub3cg-a11y-minutes.html
Present:
Avneesh, gpellegrino, tzviya, alexgrover, Bill_Kasdorf, George, CharlesL, Madeleine, laudrain
Chair: Avneesh
Scribe: Gpellegrino, CharlesL
Gpellegrino: scribe+
Avneesh: Last week we refined the definitions and rationales, anything pending from the things that we discussed last week?
Avneesh: https://github.com/w3c/publ-a11y/wiki/Definitions-and-rationales-for-Accessibility-Metadata
Madeline: George updated the "Accessibility Conformance"
Avneesh: we decided to use URL instead of URI
George: I started with a generic description, and then I mentioned EPUB
Avneesh: fine for me
Madeleine: I'm fixing URI in URL
Madeleine: "Rationale: Discovery metadata enables publications to have their accessibility exposed regardless of the overall accessibility of the publication. A publication optimized for a particular group, such as an audio book, would not meet WCAG 2.0, but it would be fully accessible to many people. The conformance metadata details the accessibility of the publication, which allows end users and educators to evaluate the suitability of the publication for individuals."
George: are we ok with that?
Avneesh: it can be improved, but I think it is ok for now
gpellegrino https://github.com/w3c/publ-a11y/wiki/Definitions-and-rationales-for-Accessibility-Metadata
Madeleine: we have to talk about "Inaccessible" and "All Accessibility Metadata"
Avneesh: can we say that something is inaccessible?..it is very difficult to say that something is inaccessible for everyone
Madeleine: I think ONIX says something about images of text ... it is true that for people looking for accessible books, some can be very inaccessible
tzviya: I think "inaccessible" doesn't convey any information
Madeleine: I think people who understand about accessible, understands what "inaccessible" means
Bill_Kasdorf: I think it can be very misused
laudrain: I think the rationale is "significant features" are missing ... it is what ONIX says
CharlesL: for me it needs to be qualified ... ONIX meaning is vision-focused (so for blind users)
Scribe: CharlesL
Tzviya: I don't think this adds anything, and as Bill says there is potential for misuse.
Bill: I agree Tzviya, we want publishers to use this they are creating this and I can imagine that a publisher will resist marketing materials so as long as it is accessible to some people they won't use it.
Naomi: distinction between inaccessible and it missing some accessibility features, it won't be understood by those that just stumbled across it. So I feel it could be misunderstood. MADELEINE: ONIX comes out of trade community, so I would have thought that they would be comfortable with this.
Avneesh: we would need equivalent in Schema and MARC. If someone wants to put it in to ONIX then they can do that but maybe we shouldn't include it.
Luc: a11y features metadata or say inaccessible.
MADELEINE: having that present then they wouldn't have to include the a11y metadata?
Luc: if it says its inaccessible, maybe there is an acceptation for this book, company is too small, or it completely changes (comic book no text) only description of images of text, there may be exceptions, asked to publishers refer to this book as inaccessible and why they could make it this way. I am just wondering.
Gregorio: if we check a book comic book and we know it not accessible for us we tell the end user and we know its not accessible to blind people.
Gpellegrino: right username now :)
Avneesh: maybe like Charles said we need to qualify this.
Naomi: if we have this binary then we need to figure out where that line is. what if I have an EPUB with video without captions would that make it inaccessible do we require WCAG-AA ... , we have all ways to say this accessModes, hazards. What if you miss one thing is it now inaccessible?
Avneesh: optimized publication it does not meet WCAG but is very accessible to a certain group eg. audio book
Naomi: if we start qualifying this flag it becomes difficult to manage
Madeleine: we are not here to decide to add more metadata, just ONIX has this right now.
Naomi: I agree
George: I agree with this and when we talk to folks from EU we may add it back depending on what they want. We do have optimized publications and Acessmode Visual.
Tzviya: it is in our best interest not to include this and there is no way we would get this into schema.org
Gregorio: we don’t' have a way that something is missing.
MADELEINE: accessMode tells us if there are images in the book (ie. Visual)
Luc: default won't be inaccessible anymore, by exception that one may be inaccessible.
Gpellegrino: maybe as an issue
Avneesh: we could keep it as a candidate (below the document) getting it implemented then we need to tighten the definition.
George: is this a binary like WCAG, if you meet A then its accessible then if you don't meet A then it is inaccessible. without getting it into schema.org
MADELEINE: maybe, this document doesn't say you can't add this metadata, like LIA wants a way to say that something is inaccessible, we are not recommending to the larger community that they should start using it.
Avneesh: lets drop it for now, but maybe in the EU wants to include it we can review this.
Bill: we are going to delete this from this document.
Avneesh: Yes
+1
MADELEINE: I will delete this from the wiki
Gregorio: I will remove it from the ONIX / Schema.org techniques.
MADELEINE: All Accessibility Metadata ... • Definition: It is a pointer to show the listing of all the accessibility metadata of the publication. It can be a hyperlink to another page or can be listed in HTML summary/details element. It should include metadata for accessibilityFeature, accessibilityHazard, accessMode, accessModeSufficient and all the accessibility metadata and conformance metadata listed above.
• Rationale: A complete list of accessibility metadata is important for advance users who would like to know presence of specific accessibility features in the publication. This listing is also important for verification of the user friendly interpretation of the accessibility metadata.
Madeleine: may want to do a pass to harmonize capitalization etc. By “user-friendly” this page right here, how can we say that more clearly?
George: by using (self reference)
MADELEINE: a11y metadata provided on (this page) What is the name of this document?
Avneesh: principles?
MADELEINE: provided according to this document.
George: User experience guide?
MADELEINE: Rationale: A complete list of accessibility metadata is important for advanced users who would like to know about the presence of specific accessibility features in the publication. This listing is also important for verification of the interpretation of the accessibility metadata provided according to this user experience guide.
Luc: wondering, related to A11Y Summary?
MADELEINE: A11Y Summary is a Human readable, this provides that but this is also including a data-dump of all the accessibility metadata.
Luc: I don't understand what it contains Schema, ONIX, ? ... , is this on some website?
Avneesh: Vital Source was doing this and was dumping all the metadata into their web page.
Luc: It could be something extracted from the ACE report. ... yes that could true
Luc: if we don't go down the line on how this should be coded it may not be useful to websites, or instead for advance users will they be able to read JSON LD / schema.org codes?
Avneesh: first page is user friendly, this is a technical page for more details ... , we can bring this example into this document.
Luc: if I have a link to the metadata would be interesting.
George: A different topic, in EPUB Accessibility specs, conformsTo in spec, if you have conformsTo then CertifiedBy is a required field.
Avneesh: if someone is claiming WCAG-AA then we need to know who is saying that.
Charles: Can you have the opposite, have a certifiedBy without conformsTo.
Avneesh: I don't remember but may need to look at that closer next time we review the specification.
Avneesh: Before we move to the next topic, what are the next steps. We have finalized the definitions and rationales, now we should move this content to principles document. Gregorio and Charles, you were working on the principles document, who will like to copy it to it?
Gregorio: I will move the definition rationales from wiki to Principals document.
Avneesh: There is another issue that we should discuss next time. The schema.org techniques document it includes EPUB techniques we should rename this document to be more in line with what’s in the EPUB.
Topic: Google Search of accessibility metadata:
Avneesh: Luc and I had a con call with Google search, Luc can you please summarize it.
Luc: knowledge KB from Google, from all websites they are curating. they are not getting this from to many different places, they do have contracts from aggregators, from publishers, they get the onix feeds from publishers/aggregators one message, they don't have to reconcile from different sources, they want to add the a11y metadata, all the onix messages, they may not use everything right now, but they store all, they could use it in the future. When they build their Knowledge graph they are able to present from any title from any book a Knowledge card on right side with title / author with all the metadata, they have a module which links to where you can buy the book from resellers in the future if there is enough a11y metadata they could have a link to this data. ..also said they will use the markup in the HTML page of the resellers not to feed the database but for usage when they crawl webpages Scripted HTML JSON but if they find HTML markup with schema.org if they find a11y metadata they may use it but in any case that would be a second thought because the KB is from the ONIX feeds.
Avneesh: Some key points that we observed from the discussions: Natural language search on a11y metadata is not perfect, if there is schema.org metadata it would take the crawlers days or weeks to pull it up from the webpages and index. better or more practical approach at this time is backdoor access, publishers, aggregators, retailers share ONIX metadata with Google. So, one should have ONIX metadata, and these entities must have a channel with Google.
MADELEINE: do we know if publishers and retailers are putting this a11y metadata in their ONIX feeds?
Luc: We are starting to do it, yes. soon as there is no issues in ACE then we convert from EPUB metadata to ONIX. In production in February.
Avneesh: And big players like Ingram are already sharing ONIX with Google.
Tzviya: Google may be the largest but there are more processors of schema.org than Google. we need to be cautious that we are metadata for google or for the world at whole. .. , want retailers to use this then we should continue to write our schema.org metadata and not just focus on ONIX.
Gregorio: we do produce ONIX a11y metadata, books in print catalog we do send Google ONIX a11y metadata right now.
George: request for search engines Google/Apple/Amazon. we are not just looking at Google ... mention that they also use MARC and libraries, we are also starting to explore. is there a master list of Libraries.
Luc: ONIX ebook distributions is done in ONIX for books we push everywhere for retailers for ONIX. very important.
George: is Pearson Wiley, for Higher education
Tzviya: its much harder for us to change ONIX metadata.
George: I know there are tools to go from ONIX to MARC
Charles: ONIX metadata 2.1 doesn't really have a11y metadata but maybe this will change here in the US since Amazon will require 3.0 by the end of this year.
Tzyia, we publish ONIX 3 for a few years but no one takes it.
Avneesh: This was mainly for information, we can discuss it further in future calls. Lets move to next topic.
Topic: Possibility of harmonization with MARC:
Avneesh: IFLA (International Federation of Library Associations and Institutions), DAISY Consortium is represented in IFLA, through Dipendra, who is responsible for work in developing countries in DAISY. He informed me about upcoming meeting of IFLA in March and asked for work items to propose. So, a proposal is submitted to harmonize schema.org / ONIX / MARC... , IFLA libraries are relying on MARC and they are starting this crosswalk, this work started from this. ... there is a possibility that I would be speaking at this group in the future.
George: LPD (Library Persons with Disabilities) if they will get into MARC that is great ... , I need to get into this, IMLS work, and even in the Canadian A11Y summit.
Madeline, I got this link from 2 different groups, it drew from the work I started but it misinterpreted some of it.
Avneesh: when we can have our next meeting? ... , next call on Feb 14, at 14 UTC.
Original raw minutes:
https://www.w3.org/2020/01/31-epub3cg-a11y-minutes.html
Present: Avneesh, wendyreid, mgarrish, gpellegrino, George, tzviya, Bill_Kasdorf, Luis, Perez, Madeleine
Action Items:
Editors of definitions and Rationales document (Madeleine, George, Charles, Gregorio and Avneesh) to improve the document as per the discussions.
Chair: Avneesh
Scribe: gpellegrino
Topic: Finalize the definitions and rationales for the principles document.
Avneesh: first task is to work on definition of rationals that is on wiki. Avneesh: https://github.com/w3c/publ-a11y/wiki/Definitions-and-rationales-for-Accessibility-Metadata
Avneesh: we can move to the definitions wiki and it would be good to edit them live
Madeleine: I can do live editing. For writing definitions assigned to me I used old documents ... screen-reader friendly: description on the Wiki ... it's not really formal
Avneesh: do we want to make it more formal?
George: I think it is clear
Tzviya: I think part of the question is who is the audience ... will it go to Schema.org?
Avneesh: the audience are online bookstores (Ingram or Amazon) ... that want to display metadata on their websites
Tzviya: Will we pass this document to other groups in W3C (e.g. WAI)
George: also libraries will use it
Bill_Kasdorf: I'm in Disability Services Office project, I think that less formal and more simple stuff is really useful to DSO
Avneesh: accessibility groups in W3C have an issue with the language they use. One discussion topic of Silver was to simplify the language.
Madeleine: I think it should be less formal
Avneesh: for now let's keep it more user friendly ... it's more guidance, then a standard specification
Madeleine: Rationale: Most available digital books include their content in true text and can report that they are screen reader friendly. Exceptions would include books where critical content is included only in images, such as graphs, charts, or equations presented as images, and books with a fixed appearance created by having an image of each page instead of true text.
Bill_Kasdorf: is it only about books or about resources in general?
Madeleine: the document is about "EPUBs" but we can use publication ... all the instances of "book" will be replaced with "publication" ... next is audiobook
Bill_Kasdorf: at the end of the definition why "it is not required to use the book"?
Madeleine: for example with images
Avneesh: the definition of audiobooks we decided was "significant content can be listened"
Tzviya: An Audiobook is a collection of audio resources grouped together by a reading order, metadata, and resources, all contained in a manifest.
Tzviya: is it intended to cover audiobooks with the new specs in the W3C? or synchronized media? ... general assumption is it will not include images ... are we talking of all versions of audio or pre-packaged media?
Bill_Kasdorf: For me the primary mode of consumption is audio, it is not a supplement to a book
Madeleine: I will take out the work "entirely"
Avneesh: ok, good
Madeleine: rationale for audiobook
George: instead of "text" should we have "publication"?
Madeleine: yes, I will replace it
Avneesh: Next: accessibility summary ... do we want be specific with teachers?
Madeleine: maybe that part can be in the rational instead of the definition
tzviya: I thinks it is better in the rationale
mgarrish: instead of teachers we can use "educators"
Madeleine: rationale ... I prefer "Must be before" instead of "can be made before" ... do we want to put "educators" in the rationale?
George: I think the definition will be used by Search Engines developers, maybe they will never see rationale
Bill_Kasdorf: do we want in the AccessibilitySummary to include what it is not accessible?
Avneesh: it is a different document: AccessibilitySummary document on how to write a good summary. For educators, we can keep it in both rationals and definition, so that people who skip reading one of the two do not miss out.
Madeleine: EPUB Accessibility Conformance definition
Avneesh: It is accurate but quite complex. ... may we have it more focused definition?
tzviya: is it correct? the value of the field will be "WCAG A/AA/AAA"?
Avneesh: right, or can be another specification
tzviya: what is the values of this definition can take?
mgarrish: it is always a URI: WCAG, EPUB Accessibility Guidelines, or other specifications
Madeleine: in the previous document we said that if it is a known URI (WCAG or EPUB Accessibility Guidelines), the UI should report the LABEL and not the URI
tzviya: I agree with George, it is easy to abuse of this metadata ... if we make it flexible to point to any URI, it will be future proof
Avneesh: do we want "EPUB Accessibility Conformance" as the static label or want to make it future proof by removing EPUB, i.e. instead of EPUB accessibility conformance: WCAG AA, we should have Accessibility Conformance: EPUB Accessibility (WCAG AA)?
Madeleine: in EPUB Accessibility Guidelines you get more than in the WCAG (metadata, etc.)
Avneesh: I think we should remove "EPUB" name to make this document more future proof. In future these guidelines can be used for WP based audio books, web publications and more.
mgarrish: I like the idea to generalize it, so we can make some changes in the future release
Madeleine: +1 for removing "EPUB"
tzviya: where will we remove "EPUB"?
Madeleine: only from the label
tzviya: ok
Avneesh: we can make this change, George can refine the definition
George: all this conformance in W3C can be very controversial ... with the European Accessibility Act it will be applied to all types of publications
Avneesh: George can also fix the rationale
Madeleine: Certified By definition ... do we want to remove "EPUB"?
Avneesh: sure
Bill_Kasdorf: I would say created or published, because usably vendors created them
Madeleine: rationale ... do we want to generalize without pointing to a specific specification?
Avneesh: ok Bill_Kasdorf: the metadata can be outside the publication
Madeleine: ok so "when the metadata about the publication"...
Avneesh: word "declare" maybe is better than "indicate"
Madeleine: Certifier Credential: description
tzviya: we should uniform the structure of the definition
Madeleine: rationale ... I think it is fine ... I would remove "and conforms to the Accessibility 1.0 specification"
crowd: yeah!
Madeleine: Certifier Report definition ... we can make it similar to the previous ones ... URL or URI? ... is a report or a list of features?
George: it can be any type of report
Mgarrish: URL is more known than URI.
Madeleine: than there is the note "Let’s consider together whether to keep this comment or not" ... about "This is very important as accessibility metadata can be generated by anyone, while an authoritative web page ensures the quality of the work done. " ... we may remove "Third-party"
gpellegrino: it is more about authentication of the certification
Madeleine: what about "verify the accuracy of the metadata"?
Avneesh: it is more about authentication ... of the certification
George: the report can be very detail, or very short
George: scribe+ Tzviya: scribe+ George
George: We are going past the top of the hour. Several people had to drop off.
Avneesh: Should we book another call to finish the wiki, for “Inaccessible” metadata related discussion I would like to have bigger group.
Tzviya: We can finish up to hazards today.
George: finished certifier report
George: moving to hazards
We finished the hazards. The updates are on wiki page.
Avneesh: Based on availability of group member present, we can keep tentative time of next call as 14 UTC on Jan 31, which is the same time as today. And we can keep 15 UTC as second option. I will ask Gregorio and Charles about their availability.
Link to original minutes:
http://www.w3.org/2020/01/24-epub3cg-a11y-minutes.html
Present: Avneesh, George, Julian_Calderazi, gpellegrino, wendyreid, laudrain, romain, laurent_, marisa
Chair: Avneesh Scribe: wendyreid
Avneesh: The previous meeting for this document was a few month ago ... we got a lot of direction and action items from the meeting ... Gregorio and Charles have made many edits and substantial progress ... so we think it is in time to have another meeting to discuss it ... some other distributors are implementing, and Julian has implemented it
Julian_Calderazi: We implemented it on copyright pages, not on a website.
Topic: Update for the changes made since the previous call:
Avneesh: Gregorio and Charles, can you provide an update?
gpellegrino: Charles and I have split the document into three documents
Avneesh: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/
gpellegrino: the first one is the principles, how to display accessibility metadata ... two techniques, one on ONIX and one on Schema metadata ... techniques for implementers with links back to the principles ... what we need to do in the CG is to elaborate the text on the different forms of metadata ... some of the sections are only titles, no explanation or text ... we need short descriptions for each ... the techniques are ok, please review, but the principles need the most work
Avneesh: From the high level view, the document is designed in two layers, the principles apply to whatever metadata format you use ... the secondary layer is techniques, which would be updated more frequently ... it currently supports ONIX and Schema, but could be expanded to MARC or others ... could we get an update from Madeline for harmonizing schema.org accessibility metadata and ONIX?
Topic: Update for harmonization of schema.org metadata with ONIX accessibility metadata.
Madeleine: The update is that I've been working with Editeur on the schema and ONIX harmonization, there have been some additions to ONIX ... I have a note out to meet with Graham, and I can provide an update once we've met ... there are a few that won't be implemented, that are features of reading systems not metadata ... there are some where, for example "screen reader friendly" but ONIX requires a number of fields and makes it more complicated ... the crosswalk page is complicated in trying to explain that ... I hope to have something clearer in ONIX ... those are some areas I am hoping to see improvement
Gpellegrino: http://www.a11ymetadata.org/the-specification/metadata-crosswalk/
laudrain: I wanted to mention, with Gregorio, we sent to Graham some new codes we wanted to add to ONIX ... I have not heard back about our request
Zakim: laudrain, you wanted to ask julien for web site url
laudrain: we wanted to add codes about tables, content navigation, contracts, complex image descriptions ... we can share that here ... we hope it can be added to ONIX soon ... I had a question about the cross walk, the missing hazard features in ONIX ... is that in review?
Madeleine: The flashing hazard was agreed to be a good addition ... one of the latest versions of ONIX might have it ... I think that the less common hazards (motion simulation and sound) are not included yet ... the most likely outcome is that the flashing hazard will be adopted
laudrain: There's a proposal circulating, we will add it
Avneesh: This is a work in progress, it's a progressive change to the documents
Madeleine: Separating them like this is helpful
Avneesh: Nice to see progress
George: I was in Washington DC last week, we are continuing to try to find someone in MARC. ... they're meeting soon and we'll try to advocate for this ... when we get someone from a different metadata group ... what do we expect them to do? ... create a crosswalk from Schema to their standard? ... once they do that, they can use the UX guide to inform the changes ... is that the work mode we expect?
Madeleine: Yes, the cross walk gives you the basics of where to look ... but the principles and techniques are really useful for implementers ... the community is the best source
George: They would then develop their own techniques
Madeleine: I think so
laudrain: My impression is that MARC is completely new to accessibility and will look at our documents ... there has been some conversion from ONIX to MARC in France ... first they have to consider where and how to add the accessibility metadata to their own standard ... they'll look at the source (ONIX from publishers) and adapt from there ... it's a bit too soon to describe the process
Madeleine: If they don't have it yet, it will be a longer process to add it
George: I believe they have added an accessibility section in the last year, referencing Schema ... but we need a representative from them
laudrain: It would be useful to give me the information before the meeting in January ... if you have any information, I can also do my own research
Avneesh: The outcomes that George mentioned are correct, the crosswalk is what we need, and the priority of metadata item that should be included in cross walk is provided by the principles document. ... let's move on to the next topic
Topic: Further improvements to the documents:
Avneesh: What are the improvements? ... we have some fundamental pieces there already ... I see the improvements in two parts, the technical improvements ... are there corrections required ... the second level is language/definitions improvement ... I hope many of us have gone through the document
Madeleine: I'm pleased to hear that there's more text to be added ... I'm wondering if there is a good place to draw that text from ... Schema doesn't have the best definitions, but W3C might? ... W3 Web Schemas ... there are some short descriptions, but I don't know if they're suitable ... the accessibility summary has a description we can use ... do we want a definition or an explanation
gpellegrino: I think that the goal in the principles is why this information is useful for the end users ... we don't explain how to represent it ... we need to explain some terms like "screen reader friendly"
Madeleine: I thought we had done that
George: I agree with Gregorio that we find out what we need from schema in terms of definitions and terms, but I am not sure where everything goes ... schema.org is the authoritative place for the information ... once we have it, we have everyone review and sign off ... the question is do we need to have writing assignments and due dates for everyone?
Avneesh: One part is the definitions, do you want contributions in a wiki and then add it to the principles page?
gpellegrino: Something like that, or a shared spreadsheet is useful
Avneesh: Github has the wiki, which we can use
gpellegrino: That's fine
Avneesh: We can work on it in the wiki and then move on to the formal page ... should we open issues in the github issue tracker to log anything we find
Avneesh: https://github.com/w3c/publ-a11y/issues
gpellegrino: I would think that would help
Avneesh: I have provided the link for the tracker ... this is how we can move ahead ... the next question is about editing, Gregorio and Charles are you ok to continue or do you need help?
gpellegrino: I am ok, this is my first time editing a W3C document
Avneesh: Would anyone like to help edit?
Julian_Calderazi: I'll join
George: I can help with writing descriptions ... managing the github docket is not something I'm familiar with
Avneesh: Others can do the commits
Madeleine: I am happy to help if you need another editor, but I'm also happy to help with the writing!
Avneesh: Julian has also volunteered ... what should be the deadline? ... for the first draft
gpellegrino: We need all of the descriptions
Madeleine: is there a submission deadline?
Avneesh: No, there is no external deadline ... the first draft will be all of the definitions and main pieces, small things can be in pending status ... we are also close to the end of the year holidays ... is end of February a reasonable timeline?
Madeleine: End of January for writing submission to be completed
Julian_Calderazi: +1 for end of Feb
Avneesh: We can start the wiki page for the definitions. I can create this wiki page with names of editors assigned.
George: Will the wiki list the missing definitions
Avneesh: Yes, this list in the principles document, we need those defined ... we have a good list of action items ... anything else we want to highlight? ... I have the list, but I will open github issue things ... the main landing page with the techniques ... when you click the links, it opens another pages where we have links for two different set of techniques ... perhaps we should have link to principles, link to schema.org techniques and link to ONIX techniques on the same page. ... other issue is for conformance, right now it is tied to EPUB Accessibility specs (with levels WCAG A, AA, AAA), but what if something is not conforming to EPUB accessibility but to WCAG or something else ... would the better way be to change the placement of the requirement ... it's currently EPUB Accessibility: WCAG etc.
George: Thinking about our future move to becoming more generic for publishing ... we'll probably have to do this for the EU directive ... you might have non-EPUB publications ... it seems like there are EPUB-specific requirements ... that are independent of WCAG ... conformsTo EPUB Accessibility specs, but not WCAG
laudrain: I agree that it could be confusing to have the multiple requirements ... we have this document called EPUB Accessibility that is not just for EPUB ... it's a big question ... I am afraid now that we've started with the ISO process, can we change the name?
Avneesh: Difficult to change the name ... changing might be possible, but we're starting the ISO final ballot now... it would require redrafting
laudrain: I don't want to change the name, but would it help to make the change you're suggesting?
Avneesh: This came from what George mentioned with not all documents being EPUB (web publications, audiobooks, etc) ... it would be helpful to not be so tied up in EPUB3 ... one more issue was in ONIX ... when we talk about hazards, it does not say anything about it not being included in ONIX
gpellegrino: Please raise it in the tracker
Avneesh: These were the main issues ... do we want to have another call in January, February? ... is it a good idea to have a call in late Jan or early Feb ... or more frequent calls?
Madeleine: It would be useful to have a working group call for the contributors ... or we can just comment on each other's work ... might be helpful to get together
Avneesh: Perhaps a call in mid-January then ... after everyone returns from the break ... I will send a doodle poll ... anything else?
George: I just want to know when I'm assigned a thing, when you send out the list of definitions, do we have a template ... description followed by rationale, make it standard
Avneesh: I'll create the page
George: Who will write what?
Madeleine: There are 10, 3 people could handle 3-4
George: Unless there's one someone doesn't understand
Avneesh: I can assign them on the wiki page ... all editors are qualified to work on them ... I'll do a random assignment
George: Avneesh is going to send out links to the wiki with work assignments
Avneesh: There's some missing pieces, these need to be fixed
Madeleine: Even just to say it's not available
George: I'm still unclear about the relationship between the principles document and the official information on Schema.org
Charles: when you mention schema you mean W3C's wiki on hazards and things ... we have control over that, Matt and I can edit it ... if there's things missing or need clarification, we can do that
Madeleine: I think we were hoping to take definitions from that page ... but it would be good to share back
Avneesh: When we wrote EPUB Accessibility, we made a lot of improvements to the wiki page based on that as well
Charles: I updated that page when we did that work ... it's not complete ... weren't we also trying to come up with a more formal document? ... the w3c wiki with definitions, there was some objection to it just being a wiki ... it should maybe a note
Avneesh: There was no decision, but it's a concern if the links were normative ... informative links are fine ... for now it is ok ... but in the long term it should be formalized
George: When something is added to schema there is a process?
laudrain: Yes, there's a mailing list
George: We met with Dan Brickley, to get anything into schema you need to go through him/the process
laudrain: You contact the mailing list and there is discussion and it's published if there's no objection
Charles: That's for terms and all of that, we have control over the values
Madeleine: For schema, the web will pick values, but we make our own to be clear
George: Great
Avneesh: thanks everyone!
Original unedited minutes: https://www.w3.org/2019/12/09-epub3cg-a11y-minutes.html
Present: Avneesh, gpellegrino, George, Naomi, Bill_Kasdorf,CharlesL, romain, mattg, Madeleine, Amy, JulieBlair
Chair: Avneesh
Scribe: George, CharlesL
Contents
Topic 1: Introduction of new member:
Madeleine has worked on Access For All, which helped to populate schema.org. She is a metadata expert.
Topic 2: Background and problem statement:
Avneesh: There was a need for presentation of accessibility metadata in a user friendly way. VitalSource started displaying schema.org accessibility metadata and it was clear from the experience that a user friendly presentation was needed. LIA brought to us the need to include ONIX. After which we created a task force of Madeleine and Graham for working to harmonize Schema.org and ONIX. There are also other metadata standards, such as Bibframe and MARC. This brought forward the need to separate this original document in two layers. One for principles and one for techniques. We can update the techniques as more metadata standards become relevant.
Views?
CharlesL1: https://github.com/benetech/UX-Guide-EPUB-A11y-Metadata
gpellegrino +1 to this approach :)
CharlesL1 Here is the link to the new W3C github new home for this work
CharlesL1 https://github.com/w3c/publ-a11y/tree/master/UX-Guide-Metadata
Bill_Kasdorf +1 This is really relevant to something I'm working on right now for client
Avneesh: How do we formulate the principles and the techniques.
Gregorio: the first part of the original document explains what screen reader friendly means. It explains the high level principles. In the high level principles, we explain what we need from the metadata. In the techniques document we explain how to extract this information from metadata.
Avneesh: Should we have different techniques documents for the various metadata types?
Matt: we should encapsulate for each metadata type , but on the other hand you could have the merger.
Bill: One compromise is to put on primary an appendix for others. It is common for a publisher will work on all three, schema.org, ONIX and MARC.
Charles: To Bill's point. Who is the intended audience? Is it libraries, vendors? If you are talking about a technique, we hadthe various approaches grouped together. However, because ONIX is so big it blew up in trying to do it.
Bill: Charles point is a goodone.
Charles: answering Bill's points, a simple concept in schema.org might require multiple items inONIX.
Bill: the different metadata idemsare very different.
Gregorio: We can separate the principles referenced them separately.
Bill_Kasdorf: +1 to whatMatt just said about the need to explain the formats
Bill_Kasdorf Good luck explaining MARC. . . . providing an example Matt; Add on to the idea if it is not simply then it becomes too complex to explain what ONIX or schema is doing.
Avneesh: Do we think Ace or SMART would use these documents?
GEORGE: agree with matt, we are nothere to document ONIX / Schema.
gpellegrino +1 to George
GEORGE: , having a consistent firstpart and then having a technique for schema, and another forONIX / MARC/Bibfram then keep it simple separate and we areproviding an easy to use example of what this can be, and weare providing a user friendly translation of this.
Bill_Kasdorf +1 toGeorge
Matt: SMART would place reference to principles.
Avneesh: So, Ace or SMART would reference the principles
Romain: We do not need to worryabout the publication process, because this is a note. We could publish as one document or we could split it.
Avneesh: Let's start with two techniques documents. one for ONIX and one for Schema.org.
George: Not confirmed, but MARCmay be referencing schema.org.
RESOLUTION: We will start with 2 techniques document ONIX and Schema.org
Madeleine will help Charles for schema.org, and Gregorio will takeONIX.
Matt has done a great job in setting it up. so it may be a lot of copy and pasting. Matt can create another techniques document for ONIX.
Bill: Is the principles whatCharles put in? Yes.
Avneesh: Lets start from here. Once The document is split in principles and techniques then we will go into further refinements.
Bill: What would be most useful are the principles. Can I send the link out?
Topic: Timeline and how we work:
Avneesh: Charles and Gregorio, what does your timeline look like?
Charles and Gregorio: We can do draft 1 before TPAC.
Avneesh: Great. And after TPAC we will do a pole for our next call.
Original minutes: https://www.w3.org/2019/09/04-epub3cg-a11y-minutes.html