Change accessibilitySummary to a recommended field

[mattgarrish]

This pull request moves accssibilitySummary to the recommended metadata list with accessModeSufficient. The definition is also slightly tweaked to emphasize that it is not for duplicating information expressed elsewhere.

The techniques document section has also been rewritten to emphasize avoiding duplication.

Have a good look at these changes and let me know if there's anything else we should say.

Fixes #2399

• Accessibility preview
• Accessibility diff

[clapierre]

Wondering Matt if we should include in the Highlights of what changed the fact that we no longer recommend having multiple summaries for different languages? Maybe we don't need to do that as it wasn't stated in 1.0.

[mattgarrish]

I was surprised to see that text in the techniques, as we already had a conversation about translations earlier in the revision and how putting xml:lang on an element only indicates what language the content is in, not that the element represents a translation of another. It was never a formal practice we mentioned in the specification.

The problem is that we discussed this in the publ-a11y repository (in w3c/publ-a11y#94). We got to the right answer there, but it doesn't look like anyone spotted that we were saying the opposite here in the techniques.

It wasn't a requirement or recommendation, so we technically aren't reversing anything substantive, but I can add a change log entry to highlight that the incorrect advice has been fixed easily enough.

[mattgarrish]

For anyone interested, the original wording didn't use the word translation, but the text suggested that was the use case:

Do not repeat this property unless it contains the summary in another language. In the case of multiple summaries, use the xml:lang attribute to differentiate the language.

I don't think we want to try and explain what multiple summaries with different xml:lang attributes represents. Better to just say that they are not translations.

[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.