Repository navigation
Make summaries recommended and update guidance on use #2399
Description
Per the discussions that went on in #2116, the new proposal is to both change schema:accessibilitySummary from a required to recommended field and provide additional guidance on using it to supplement the other discovery metadata so it is not repeating information.
Activity
iherman commentedon Aug 26, 2022
The issue was discussed in a meeting on 2022-08-26
List of resolutions:
View the transcript
2. Changes to accessibility conformance identifiers and
accessibilitySummary.See github pull request epub-specs#2400.
See github pull request epub-specs#2401.
See github issue epub-specs#2399.
See github issue epub-specs#2398.
Avneesh Singh: the main issue here is how to handle
accessibilitySummary.… should it be mandatory, or only recommended?.
… we settled on recommended, and highlight the cases where you should definitely provide this data.
… this also requires a change in something else. People were using this field to explain a11y conformance.
… mgarrish suggested that we should make the conformance field more human-friendly.
… which means you don't need to explain this in
accessibilitySummary.Avneesh Singh: so these are the two PRs.
Charles LaPierre: agreed. In addition, mgarrish also clarified that there should only be one
accessibilitySummary, in the language of the epub.… the
accessibilitySummaryis now recommended. It should include anything that is not captured in the other (machine readable) meta fields.… not duplication.
… we will rewrite a11y best practices around how to display epub metadata to users.
George Kerscher: the EUAA will require the presentation of a11y data, so we feel that if the other fields that are currently machine readable can be communicated to users via best practices, then accessibilitySummary can just be for anything else.
John Foliot: what happens if the epub is in more than one language? Then what lang should
accessibilitySummarybe if there should only be one? Multiple languages in one?.George Kerscher: there's always a base language for the publication, so the accessibilitySummary would use that language..
John Foliot: the
accessibilitySummary, as explained, is intended to be human readable. So screen readers should be able to read it. I should be able to use tools like language tagging, pronunciation markup, etc..… so maybe that human readable summary should support multiple languages.
George Kerscher: the name summary is inaccurate. It's not a summary of the whole document. It uses the term summary as a holdover from Schema.org.
… we would propose to reference the Schema.org description in the a11y best practices guide, to make this clear.
Avneesh Singh: a lot of the details which have been shared about a11y guidelines have been working in Publishing CG.
Ivan Herman: i'm looking at preview of the spec where description of
accessibilitySummarydoes not make explicit reference to languages.See github issue publ-a11y#94.
Ivan Herman: also
accessibilitySummaryis part of the package document, so you can repeat it in a different language?.Wendy Reid: there's a note in the PR about not repeating the
accessibilitySummary.… "do not repeat this property to declare translations...".
… since there is no hierarchy, the RS might pick the wrong language.
Ivan Herman: it's an xml document, so adding a language is technically possible.
Avneesh Singh: we've been discussing
accessibilitySummaryfor a couple months now, JF has made good points but we are in CR now. We will defer these things to the next version rather than expanding our work on this currently.Wendy Reid: any other questions re.
accessibilitySummary? Changes to conformance identifiers?.