Should accessibilitySummary be a recommendation?

[mattgarrish]

As discussed on the community group's call today, accessibilitySummary has a number of shortcomings at the moment, from being language-specific to not being clear what to put in it to it not always being needed unless there are other details that can't be expressed through other metadata.

We currently require this metadata be set for conformance, though, which forces people to put something into the field even if it's not useful.

The question is whether we should move this field to the recommended category so that it can be omitted if the publisher has nothing useful to add that the other metadata doesn't already communicate.

Making this change would not invalidate any existing content as it as a loosening of the current requirement.

[GeorgeKerscher]

I believe the AccessibilitySummary should remain a "must" for version 1.1 of the specification.

First, it is late in the process for EPUB 3.3 RC to change at this point.
Second, Many producers of alternative materials will want to use this field to identify the enhancements they have made to a publication and share this information in their systems. The FRAME project is an example of this.
Third, it is a common type of field across Schema, ONIX, and MARC.
Finally, we intend to produce guidelines for this field, which will reduce objections people have made about this metadata field.

[clapierre]

Benetech's GCA program has this also as a requirement as we are enforcing the Accessibility 1.0 specification and over two dozen publishers and conversion venders are already putting accessibilitySummary into their publications and have been for a few years now.

[danielweck]

FYI the next version of Thorium will display the "accessibility summary" alongside the publication's dc:description metadata, both of which are usually provided in the same language as the book "title", etc.

So from the perspective of a reading system implementor, "accessibility summary" is really no different from dc:description, in the sense that we just display the text in its given language. Technically speaking, the xml:lang and dir attributes can be set on the dc:description OPF XML element, but Thorium and its underlying software components currently do not support such language variants (plus, I personally have not come across publications that contain multilingual descriptions).

Note that at this stage Thorium only presents "accessibility summary" and ignores other metadata such as "access mode" etc. We will be refining our UI design with the help of the "UX guide" specification. We are also thinking about integrating accessibility metadata in the new bookshelf table layout: data grid with columns ordering and filtering, rows pagination, and a user experience that centers around fuzzy-matching text search. We will consider introducing enumerated values such as the various "access modes", in order to facilitate search for metadata fields that have well-known / pre-defined keywords (with their associated translations).

[mattgarrish]

We sort of came to the conclusion not to change by end of the discussion on the CG call, but we have to make the monumental leap from CG to WG now and formally answer the question wearing our hats as the wise holders of the sacred knowledge.

So, what's your take on trying to solve this in the time we have left, @avneeshsingh? Best to defer?

Do you want to argue for making it a recommendation @gregoriopellegrino, or are you okay with maintaining the status quo?

[avneeshsingh]

We heard some concerns from LIA and EDRLab for usage of AccessibilitySummary in the supply chain. So, am opening this issue for further discussion.

[gregoriopellegrino]

Here are our accessibility summary considerations regarding the mainstream digital publications supply chain in Europe:

• the European Accessibility Act puts content producers in front of the major challenge of making hundreds of thousands of digital publications accessible, so we think it is important to minimize activities that require manual intervention and possible inefficiencies
• we think that the accessibility summary is important and that it should contain the information that cannot be expressed with the other metadata (e.g., "contains knowledge maps useful for users with dyslexia"), so as not to repeat and duplicate information that is already available in machine-readable mode
• that is why the accessibility summary metadata in our opinion should not be mandatory
• in our view, key accessibility metadata should be passed to the supply chain in machine-readable format so that it can be parsed, filtered, processed, etc.
• in our vision, it is the responsibility of those who develop graphical interfaces for ebook metadata (lending platforms, ebook stores, reading apps, etc.) to transform machine-readable metadata into text form for the endusers
• for this we have the User Experience Guide for Displaying Accessibility Metadata and we are gathering user feedback to refine them
• for platforms that have difficulty implementing the User Experience Guide for Displaying Accessibility Metadata we could develop a script (open-source) that automatically takes the metadata and returns a text form, ready to show to the user

Finally from the initial feedback we have had from Italian users with respect to how accessibility metadata should be presented we got that they would like it organized in a uniform and consistent way across all titles on a single platform and - where possible - also across different platforms; we think that with accessibility summary production in the hands of content creators this is not achievable.

[llemeurfr]

We (EDRLab) share LIA's concerns about the mandatory use of the Accessibility Summary in the supply chain. The "Normes et Standards" working group of the french publisher's association agrees that this field should be optional to avoid redundancy with other machine-readable accessibility metadata, to speed up the work of converting ebooks to an accessible format and, last but not least, to provide end-users with a uniform experience of exploring ebook catalogs across different publishers, different titles and different platforms. They agree that if there is no accessibility issue, "accessibility conformance" is sufficient, which makes Accessibility Summary redundant and accessory.

The "Normes et Standards" working group recently published a technical guide (in french) for Accessible EPUB production. They currently recommend using Accessibility Summary to specify precisions relative to the "accessibility conformance", which they find too restrictive. They also indicate that Accessibility Summary can be used to notify what is preventing from full accessibility. This also acts as a reminder for service providers who should update the EPUB according to technical advances (especially for alternative texts).

In conclusion we think that
a/ the property should be optional
b/ the current specification of this property (1) can stay as-is.
c/ the recommendation of the UX guide should be to display it "below" information extracted from machine-readable metadata, only when it is present in the metadata set.

(1) An accessibility summary provides a brief, human-readable description of the accessibility characteristics of an EPUB Publication, or lack thereof.

[vincent-gros]

At Hachette Livre (France) we share LIA's concerns as well.

After years and thousands of accessible EPUBs, we can see consistency in providing machine readable information, but the summaries don't reach the same level of consistency, nor the same level of richness of information.

The machine readable information can be displayed in an homogeneous way (and in any languages, not only the language of the book) by stores, reading systems, and so on, and can be used to filter accessible ebooks by features/capabilities. And thanks to ACE, we can check them (at least we can check if the values exist and are correct).

[HadrienGardeur]

We have similar concerns at De Marque: in our experience, what we receive currently in this field is at best unhelpful and can be harmful to the user experience.

We should only resort to strings when no other options are available, and in this particular case, schema.org offers plenty of alternative options to express the same data in a more structured way.

In our opinion:

• accessibilitySummary should not be required
• the User Experience Guide for Displaying Accessibility Metadata 1.0 should explicitly recommend using other metadata as the primary mean to convey information, and the summary should not be listed near the top of key information (it's currently in third place)

[avneeshsingh]

The issue was discussed in accessibility task force of Publishing CG:

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?
Charles: 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.

[LaZay]

Within the "Normes et Standards" working group of the French publisher's association, the redondancy of the a11y summary with detailed a11y properties has been discussed indeed. Members said that this summary would better be generated automatically, to guarantee the consistency between the a11y summary, and the detailed a11y features. Some publishers said that they would continue to deliver their own a11y summary to the bookshops/libraries though, in order to control its content (as optional does not mean forbidden...) . Other publishers said that they would stop delivering the a11y summary, as soon as it becomes optional (one less task on their side), and let the bookshops/libraries manage the a11y summary, if ever needed.

I do remember discussions within the metadata interprofessional French task force, saying that two levels of information on accessibility were required for bookshops, and libraries:

• a first level with general information readable by everybody (including impaired, AND not impaired people) => the a11y summary ?
• a second level with more detailed information dedicated to people specially interested in accessibility (impaired people, or buyers for impaired people), and want to "zoom", get down into detailed a11y features (such as a11y standards, level, etc.) in order to make a purchase decision. => the detailed a11y features ?

So it seems that there is a need for a general a11y summary.

But there are still some issues:

• Can the a11y summary be generated fully automatically for a nice and reliable human reading on the sole basis a11y detailed features? What does the absence of a detailed a11y feature mean? A lack of a11y metadata on the product, or a lack of a11y service inside the product?!...
• Who must provide the a11y summary to the end user (and guarantee its consistency with the a11y detailed features)? Publishers-distributors versus vendors-loaners? How can we make this summary mandatory on a bookshop/library web site? Unfortunately, I do not see any technical means to force the last link in the book chain (vendors-integratorssupply) to provide an a11y summary. I am afraid that only interchange formats used in the middle of the book chain, (i.e. ONIX or OPF-schema) can provide the means for this.
• Don't you think an optional summary will be even worst than a forbidden/mandatory one? Bookshops, and libraries will receive very heterogenous a11y metadata then: with/without summary... :-/ What will be their policy in that case? :-(

[wareid]

I agree with the concerns from LIA, Hachette, and De Marque, the standardized fields are much more consistent and easier for us to work with in terms of consistent display.

I do believe there is a place for accessibilitySummary for data that is not covered by the metadata or where more detail is required. Making it mandatory would not be the way to do this though, as for content where the metadata fields cover all of the details we'd likely get a standard "This book is accessible" type summary that is simply repeated throughout a catalogue, and offers no additional benefit to the user. Without standard text, we'd also get infinite variations on a similar summary, which means platforms won't be able to filter out the unnecessary information. Making it optional does present the risk we'll stop seeing them at all, since we know from experience optional features tend to get dropped, but I do think keeping it mandatory introduces more noise than benefit, at least at this point in its usage.

[avneeshsingh]

The issue was further discussed in the Accessibility task force of Publishing CG. The extracted minutes are as follows:

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

[avneeshsingh]

The above discussion and conclusion happened in Publishing CG, but the decision for these changes need to come from EPUB 3 WG. Therefore, I am summarizing the conclusion here, and the EPUB 3 WG can vote for it.

We should make the following changes in EPUB Accessibility 1.1:

• We make the values strings of conformsto more human readable, while maintaining its machine readability, so that we do not need to explain the conformance in Accessibility Summary metadata.
• AccessibilitySummary is right now a mandatory field in EPUB Accessibility 1.1, we should change it to a recommended field.
• We explain where it is very important to provide AccessibilitySummary (we may like to add a note for it)

[gregoriopellegrino]

+1

Great solution for me, thank you.

[cmussi]

+1
It seems a very good and balances proposal
Thank you very much

[murata2makoto]

+1

[llemeurfr]

+1
with the additional request that in the display guidelines related to accessibility metadata, it is made clear that the accessibility summary should be displayed as a complementary field, after labels processed from machine-readable metadata, and never the only field displayed to the user.

[vincent-gros]

+1

Great proposal, thank you.

[avneeshsingh]

Thanks everyone for providing inputs.
I think that we have provided sufficient time for the community to respond, and we have received all the comments in the support of the resolution.
Therefore the issue is resolved, with the following actions:
We should make the values strings of conformsto more human readable, while maintaining its machine readability, so that we do not need to explain the conformance in Accessibility Summary metadata.
AccessibilitySummary is right now a mandatory field in EPUB Accessibility 1.1, we should change it to a recommended field.
We explain where it is very important to provide AccessibilitySummary (we may like to add a note for it)