Make summaries recommended and update guidance on use

[mattgarrish]

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.

[iherman]

The issue was discussed in a meeting on 2022-08-26

List of resolutions:

• Resolution No. 2: Merge PRs 2400 and 2401.

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.

Dave Cramer: ak ch.

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 accessibilitySummary is 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 accessibilitySummary be 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 accessibilitySummary does not make explicit reference to languages.

See github issue publ-a11y#94.

Ivan Herman: also accessibilitySummary is 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 accessibilitySummary for 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?.

Proposed resolution: Merge PRs 2400 and 2401. (Wendy Reid)

Ivan Herman: +1.

Charles LaPierre: +1.

Wendy Reid: +1.

Matthew Chan: +1.

Avneesh Singh: +1.

Brady Duga: +1.

Masakazu Kitahara: +1.

Dave Cramer: +1.

Resolution #2: Merge PRs 2400 and 2401.