accessibilitySummary and display language

[gregoriopellegrino]

The accessibilitySummary is the only free text metadata that is meant to be displayed directly to the end user.

Normally the accessibilitySummary is written in the main language of the book text, but there may also be more than one accessibilitySummary, with different lang attributes, to report the text in different languages.

I think it is important to point out to the developers of online catalogs to be careful to correctly indicate the language of the accessibilitySummary in their GUI. In fact, it could happen to show the information of an Italian book (with Italian accessibilitySummary) in an English GUI.

In this case, for the accessibilitySummary, it would be necessary to force the Italian language (for example with the HTML attribute lang="it"), otherwise the screenreader would read the Italian text with the English voice, which makes it incomprehensible.

Finally I think we should also indicate how to behave in case the ebook has more than one accessibilitySummary (with different languages). My proposal is:

• if the language of one of the accessibilitySummary matches the language of the GUI of the catalog, show the one
• otherwise show the first one that appears inside the OPF file

[clapierre]

I agree what you said above with the default accessibilitySummary shown in the native GUI language of the GUI, however, I would like to see if there are multiple versions of the accessibilitySummary in different languages that we recommended a method to show the other versions.

The publisher put the other language options in there for a reason. In the case of Canada where there are two official languages it would be great for a bilingual person to read these summary's in their preferred language.

For example a dropdown where you can switch to the other language. Also if the entire GUI has the ability to switch languages the accessibilitySummary shown should also switch accordingly.

[TzviyaSiegman]

Can we get a reality check here? I fear that we are venturing into the world of specifiction or unicorn specs. Creating AccessibilitySummary in multiple languages and documenting a GUI does not sound very tenable to me. I would love to hear from @wareid @duga and @hadrien about implementability.

[wareid]

The Kobo website is currently localized into over 13 languages, and our devices and apps into more than that. We do not currently translate any metadata values sent to us by the publishers because with over 6 million titles in the library, it would be untenable. It costs a great deal of money just to handle the translations of UI components across web, apps, and devices.

There are also accessibility issues with this idea. It would also be misleading. If a book is in a language, but it's metadata in another one, the user could be confused as to the language of the book, and we'd never want that. The other issue with expecting translations for any metadata field is that automatic translations are often poor, especially for any technical or contextual terminology.

[clapierre]

The specification does not prevent more than one accessibilitySummary as far as I know and if a publisher does provide more than one say English and French if this book is bilingual then shouldn't we provide guidance to Bookstores / Libraries etc. on which version they should display? If they always display the first one it encounters then you could get into the situation where the French accessibilitySummary is displayed even though there is an english version within the EPUB and the EPUB is primarily in English.

[clapierre]

@wareid

We do not currently translate any metadata values sent to us by the publishers because with over 6 million titles in the library, it would be untenable. It costs a great deal of money just to handle the translations of UI components across web, apps, and devices.

Right and we wouldn't want you do translate those, I believe the idea is if a publisher wants to add more than 1 accessibilitySummary for different languages themselves in the metadata how should we guide bookstores etc on how to display these.

Another option might be to just display all of them with the appropriate language tags set.

[mattgarrish]

I'd add a note of caution that epub doesn't define translations of metadata, so unless a publication truly contains multiple versions of itself in different languages, it's probably not a good idea to have more than one accessibility summary. (Even then, the publisher is going to have issues with representing titles, etc.)

We went through this problem earlier in the 3.3 revision. An author name may be identified as being in language different from the text, but that doesn't make it a translation.

It's part of why multiple renditions was conceived, but my experiences with that spec makes me believe publishing single publications with two or more complete versions of the text in different languages is not a common desire. My understanding has been that publishers prefer to create separate publications for each when it does arise. If you used multiple renditions, and they worked, each package document could have its own summary, as well as language-appropriate titles, etc. making this problem moot.

So while there may be no harm in saying to pick the language-appropriate summary when there are multiple versions, I suspect there are bigger issues that are going to impact the display of such metadata, not just the accessibility stuff. I wouldn't spend a lot of time trying to solve it, but only note that the issue exists.

[mattgarrish]

Another option might be to just display all of them with the appropriate language tags set.

I wouldn't be surprised if the publisher wrote both summaries together in a single metadata element, as that's likely what they'd have to do to get all the other language-specific fields to render.

[wareid]

Just from the angle of practicality, I don't know of a case in the market today where a book in one (or even more) languages would have any of it's metadata in more than one language. Is this actually something people need or would use? No other metadata fields are provided in multiple languages as far as I have heard or seen.

[mattgarrish]

Just from the angle of practicality, I don't know of a case in the market today where a book in one (or even more) languages would have any of it's metadata in more than one language.

Well, ya, I can't cite an instance as I don't know how it would work beyond cramming the two languages together. If the government of Canada, using Charles' example, wants to put out a bilingual publication, it's going to have challenges just getting the titles to work. If you don't run both titles into a single tag, the user probably has their chance to complain to the office of the commissioner of official languages...

No other metadata fields are provided in multiple languages

Technically they all are, but what does it mean? If you specify a second title with a different xml:lang on it, is that the version of the title in another language or is it a subtitle in another language? By definition, it's the latter because we don't define the use of xml:lang as representing a translation.

It's all very head spinning. We may want to say something about this in the core spec - like in the xml:lang attribute definition that using it does not represent a translation of any other field.

[GeorgeKerscher]

Hi, In the Package.opf we find the accessibilitySummary and the other accessibility metadata. In here we also fine the DC metadata and we find <dc:language>en</dc:language> So, this titles is in en which is English. It seems that that the accessibilitySummary would also be in English. Unfortunately, Doubling Core fields can be repeated. I did not find a xmllang attribute on the package.opf. This seems to point to the difficulty of providing an accessibilitySummary in a different language than what is defined in the DC Language field.

[mattgarrish]

It seems that that the accessibilitySummary would also be in English.

Typically, yes, but the language of package document metadata is set by the xml:lang attribute on the package element, not the dc:language element. The language can then be overridden on any metadata element. xml:lang is defined in the shared attributes section.

The problem is that the presence of the attribute doesn't mean a second instance represents a translation. Going by how other elements are treated, it would suggest a two-part summary with each part in a different language. Both parts would be applicable to any representation in a UI.

[mattgarrish]

And I just noticed this text buried below the example in the accessibility spec techniques:

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.

Absent a defined way to provide translations of metadata, we shouldn't be suggesting this will work.

[gregoriopellegrino]

I think there's some misunderstanding about the issue, maybe it's better to talk about it in a voice call? :)

[GeorgeKerscher]

On the Accessibility Summary call on May 19, we discussed this issue. We decided not to close it, because there were important people missing. However the discussion was interesting.
First, there are many things in EPUB that do not have duplicate information. For example, we do not have the TOC in multiple languages. Starting down this path in the accessibility group would be too much. It is probable that very few titles will be in two languages. Normally a publisher will just publish the title in the other language. There are titles in one language that teach about another language, so there is a lot of language changes in the title. However, the title still has the primary language. For example, a book in English which teaches the Ancient Greek language, would have the accessibility summary in English. We went down the road of multiple renditions, and that did not work. We do not want to go down a path of overengineering.

The current recommendation is to simply have a statement that the accessibility summary should be in the language of the primary publication.

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