From EditEUR's feedback:

Certified By

Value: Textual Data from metadata
This technique relates to Certified By principle.
Not available in ONIX
New code for list 196 – value 93

In the next version of our User Experience guide, I believe we should provide guidance on filtering for accessibility metadata. Those records which contain accessibility metadata should be displayed before others.

Implementers would benefit from having guidelines on which set of metadata is associated with specific EPUB 3 profiles. This is especially the case for EPUB 3 with MO.

The example 9.1 presents the set of metadata an EPUB 3 with MO requires.

Therefore it would be useful to add before the example a sentence like "This set of metadata corresponds to EPUB 3 publications with Media Overlays".

In the User Experience Guide for Displaying Accessibility Metadata 1.0 point 4.9 and Display Techniques for ONIX Accessibility Metadata 1.0 point 2.9 we find : All Accessibility Metadata Value: Link to complete list of all metadata fields

There is a link to a full EPUB Accessibility exemple

For ONIX we have the following indication : For a complete list of ONIX accessibility metadata refer to the crosswalk. wich is now outdated.

1. The ONIX link should now link to the updated Crosswalk between metadata formats.
2. Do we have to show all ONIX list 196 codes (if presents) ? Do we have to show only the ones with a schema dot org reference ? Am I missing something ?

Can be identified by following the crosswalk:

accessModeSufficient: textual

equals

List: 81; Code: 10 combined with List: 196; Code: 10 means all text is actual text. Note that List: 81; Code: 10 on its own (without List: 196; Code: 10) admits the possibility that the ‘text’ is inaccessible because it is an image of text.

In March 24, 2020 con call, the group decided to explore addition of Low vision friendly field in the user experience guide.
The User experience guide defines only high priority fields, while all accessibility metadata are available on another web page. Therefore, with the current arrangement advance users can make out from all accessibility metadata page, if a publication is low vision friendly or not. So, the check points for including this field in user experience guide are:

• Is it possible to extract accurate information for "Low vision friendly" from accessibility metadata (schema.org a11y metadata, ONIX a11y metadata etc.)
• The priority of Low vision friendly field, is it a sufficiently high priority field that should be added to fields to be displayed.

Right now all the metadata examples in EPUB Accessibility Metadata are for EPUB 3, we know that this metadata can also be included in EPUB 2.

Maybe put a note about this? Or include examples for EPUB 2 as well?

We need to add the following to the section of each document and add hard returns on long lines in our examples.

<style> /*prevent examples from horizontal scrolling*/
			pre,
			code {
				white-space: break-spaces !important;
			}
</style>

From Madeleine's email: https://lists.w3.org/Archives/Public/public-epub3/2020Feb/0004.html

EPUB accessibility metadata includes the important property displayTransformability, which is sometimes called reflow capability. Text that can be transformed into different kinds of displays can meet the needs of a wide range of readers by providing the text in synthesized speech, large print, alternate colors, braille, or any other presentation. Nearly all ebooks provide displayTransformability. Exceptions include picture books or other visually-presented text, where the text is part of an image, and fixed-format large print books, which are intended to meet the need for large print but do not have transformable text. Audio books, which have no true text, would also lack displayTransformability. Any ebook that offers displayTransformability is largely accessible to many users and would qualify as Screen Reader Friendly.

The techniques for schema.org accessibility metadata (1.) also has double core and EPUB metadata vocabulary. Therefore it may not be named as schema.org metadata techniques.
1.
https://w3c.github.io/publ-a11y/UX-Guide-Metadata/techniques/schema-org.html

Unicode has 92,865 CJK ideographic characters. But each language uses a small subset. Annex A of ISO/IEC 10646 shows a list of character collections relevant to Japanese text. (Note: Annex A also provides collections for other languages as well). Each of the listed character collections contains less than 10,000 characters.

Assistive technologies (e.g., Japanese TTS) are unlikely to handle 92,865 CJK ideographic characters. According to a report from a Japanese ministry in 2015, most TTS engines support 6355 characters in JIS X 0208 only. I have not heard significant improvements since then.

Moreover, authors of textbooks or books for children use even smaller subsets for pedagogical reasons. For example, 1006 CJK ideographic characters are taught in Japanese compulsory education.

I thus think that accessibility metadata should be able to indicate (1) which character collection is used as a basis and (2) which character beyond the specified collection is used as exceptions, which are sometimes necessary. I believe that this is good for other CJK countries. Moreover, since no languages and no TTS engines support all Unicode characters, I guess that this is good for everybody.

As discussed in the PCG-A11Y meeting at https://www.w3.org/2021/02/05-pcg-a11y-minutes.html

We decided to change how accessModeSufficient=audio is exposed to end users.
"Audio Book" has a preconceived public opinion of what that is so instead we will change our label to "Full Audio" instead

This impacts all 3 documents

• https://w3c.github.io/publ-a11y/UX-Guide-Metadata/principles/#audiobook
• https://w3c.github.io/publ-a11y/UX-Guide-Metadata/techniques/epub-metadata.html#audiobook
• https://w3c.github.io/publ-a11y/UX-Guide-Metadata/techniques/onix.html#audiobook

In addition to just changing the label we also need to update the definition of what "Full Audio" means as well as the "Rational"

Currently:

4.2 Audiobook

Values: Yes / (if No - Omit this section)

Definition

An indication that this publication is an audiobook which is designed to be used by listening. This designation can be applied if text will also appear on a display as long as it is not required to use the publication.

Rationale

Audiobooks are considered optimized publications. They may not meet all accessibility requirements if they lack visible text, but they provide access to the publication for specific users who require audio, including users with dyslexia or visual impairments. Providing a way for users to search a collection for audiobooks will support these users, and including this information in the metadata displayed will also alert users for whom audio is inaccessible. This piece of metadata should be included only if the value is "Yes". Since most digital publications available are not audiobooks, it is only important to include this metadata in the user interface for those that are.

The entry page has two links, one to principles and other to techniques. On clicking the techniques link another webpage opens up, which has links to two techniques webpages, one for schema.org and one for ONIX.
Instead of this, it would be good to place link to principles, link to schema.org techniques and link to ONIX techniques on the single entry page:
https://w3c.github.io/publ-a11y/UX-Guide-Metadata/

The definition of accessibility conformance metadata is written from perspective of dc:conformsto, which uses URL, on the other hand ONIX uses codes. This definition should be rewritten in abstract way. Copying the text below:
To report the accessibility conformance of a publication, the metadata term conformsTo must be provided. The conformsTo term requires a specific URL that identifies the level of conformance of the publication. The values for an EPUB publication are:

• http://www.idpf.org/epub/a11y/accessibility-20170105.html#wcag-a
• http://www.idpf.org/epub/a11y/accessibility-20170105.html#wcag-aa
• http://www.idpf.org/epub/a11y/accessibility-20170105.html#wcag-
  The above URLs indicate that the publication meets the EPUB accessibility requirements and the corresponding WCAG levels of A, AA, and AAA.

If a publication is optimized for a particular user group, e.g. an audiobook, it would not conform to WCAG guidelines, but it may be perfectly useable by a particular group, e.g. persons who are blind. In this case, the conformsTo term must point to a URL that identifies the specification used to create the optimized publication.

The improved version is as follows. Further improvements are welcome.
To report the accessibility conformance of a publication, metadata for accessibility conformance should be provided. It declares the accessibility standard or accessibility specifications to which the publication conforms. The value can be a URL or a code which identifies the accessibility standard or accessibility specifications.

In case of EPUB publications, it will usually point to the EPUB Accessibility specifications or WCAG. If a publication is optimized for a particular user group, e.g. an audiobook, it would not conform to WCAG guidelines, but it may be perfectly useable by a particular group, e.g. persons who are blind. In this case, the accessibility conformance metadata should identify the specification used to create the optimized publication.

Currently we are inconsistent in how we are displaying this very technical metadata in our documents.

Some places we show the raw values with camelCase single words (i.e. . In others we convert these words into separate words)
Accessibility Features:
alternativeText
longDescriptions
printPageNumbers

vs.
Accessibility Features:
Alternative Text
Long Descriptions
Print Page Numbers

4. Order of Key Information
   Displaying any hazards if present and linking to all the accessibility metadata including all the specific accessibility features such as: image descriptions, mathml, table of contents, etc.

Screen Reader Friendly
Full Audio (if present)
Accessibility Summary
Accessibility Conformance
Certified By
Certifier’s Credential
Certifier’s Report (if present)
Hazards
All Accessibility Metadata

I am a little confused why some of these have (if present)?
I think all of these may or may not be present so not sure this gives us anything.
I think we make a blanket statement at the top saying that each of the metadata below should only be displayed if preset.

There are only two metadata properties that we will always display even if there was no metadata present and those are:
Screen Reader Friendly: unknown
Hazards: unknown

All other metadata if it isn't present won't be displayed should we point this out?

My name is Miriam Hlavaty and I work in Statped. We have been testing a lot of the educational books made by publishers in Norway to see how well suited they are for students with special needs (sight impared, low vision, dyslexia).
Regarding the point 4.2 Full Audio (this question concerns educational books.) In our country several publishers provide books where some of the content has been recorded and is accessible as audio files (in addition to the written text). Basically it is the main body text that has been recorded and exercises, examples in the sidebars etc is not recorded. How should publications like this be marked in their meta data?
Another question: a lot of the same books also contains a built-in synthetic speech that can be used to access some of the other texts. Generally this does not work to well as the speech synthesis is unable to render correctly a lot of the special signs used in for instance science books, but the publication still has recorded audio and the possibility for text-to-speech. Is there a standard for how to mark books with built-in text-to-speech technology? It should be added that in some of these books the built-in synthetic speech technology can only be accessed by marking or highlighting the text you want to have read out load so it is not particularly accessible for users with low vision or motor skills issues.

From EditEUR's feedback:

I suggest change ONIX feed to ONIX record

I suggest to:

• remove https://w3c.github.io/publ-a11y/UX-Guide-Metadata/techniques/
• create a super simple page like: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/

In the EPUB techniques document, it says:
NOTE
The above three URIs could change in the future since they point to an IDPF page; this work has been moved to the W3C. If a change occurs, other URIs will be recommended.

Should we change these as well?

The EPUB display techniques refers to the "OPF file" but that's very colloquial. It might be better to change these to "package document" so they match standard epub 3 phrasing.

Also, stating that the document is "usually found in oebps/package.opf" is also dating the document to pre-EPUB days. It might be helpful to drop this statement and instead link across to the package document definition in the EPUB spec.

Section 4 of "User Experience Guide for Displaying Accessibility Metadata" is "Order of Key Information".

The Technical Committee of the Japan DAISY Consortium plans to introduce three sets of accessibility metadata (ruby, horizontal/vertical writing, and ruby). I suppose that nothing in this draft community group report presents the addition of these sets, but I just want to check.

This publication is being produced by the W3C Publishing Community Group, instead of the old name EPUB Community Group. I believe this should be changed. This also means the reference to the correct mailing list archive should be changed from what it is now, i.e. it now says, "If you wish to make comments regarding this document, please send them to [email protected] ("

Hi everyone,
We open a project under EDRLab flag to implement the guide in a french context. We plan to :

• translate the guides (in progress)
• build an example page in french (in progress)
• get users and distributors feedback thru working groups
• synthesize, resume and give a feedback here.
  This message is to give context about the next issues i'll be opening.

Both in terms of the property attribute and the metadata value:

• are the extraction instructions case sensitive?
• how to behave in case of spaces: for example a list separated by comma-without-space or a list separated by comma-followed-by-space?

In reviewing the UX Guide for Displaying Accessibility Metadata, I had one question about the order of key information in regards to audiobooks.

I think knowing whether content has audio is really important, but I think placing audiobooks in this order might be incongruent with how content metadata works in practice, and also a little late in the experience for a user to find out if the content is audio.

I think emphasizing the content type (EPUB, audiobook, etc.) should be elevated into the primary metadata (like in section 3, example 2), with the accessibility information containing details like whether there is a transcript, media overlays, or other features.

Alternately, audiobook could be used to tell users that an audio version of the book is available, but I think it's awkward for users to only find out something is an audiobook in a sub-section. In practice, it is probably unlikely and potentially repetitive to have the information there as well.

From EditEUR's feedback:

Audiobook

Values: Yes / (if No - Omit this section)
This technique relates to Audiobook principle.
This information can be retrieved from ONIX code list 81; Code: 01: Audiobook. ‘
Can also be retrieved from ProductForm AJ, AN, AO – Digital audio books. – probably more common and reliable than list 81.
(xpaths for these)
/ONIXMessage/Product/DescriptiveDetail/ProductForm[. eq ‘AJ‘]
/ONIXMessage/Product/DescriptiveDetail/ProductForm[. eq ‘AN‘]
/ONIXMessage/Product/DescriptiveDetail/ProductForm[. eq ‘AO‘]

The ARIA in HTML spec defines (among other things) document conformance requirements for use of ARIA attributes in HTML, which are normative author-level rules.

The "rules of ARIA attributes usage by HTML language features" table provides normative requirements notably on where DPUB ARIA roles are allowed.

We’re too late for the CFC for moving to CR, but I believe the Publishing Working Group A11y TF should do a group review.

I already opened some issues (#99, #100, #101), but these should be reviewed by our TF.

cc @TzviyaSiegman, @mattgarrish, @avneeshsingh

The display document titles don't use exactly the same naming convention. It doesn't seem necessary to add "for EPUB" to any of these documents, either. My suggestion would be to shorten them to:

• User Experience Guide for Displaying Accessibility Metadata
• Display Techniques for EPUB Accessibility Metadata
• Display Techniques for ONIX Accessibility Metadata

In section three a sentence says: At a very high level when displaying information about an EPUB you may just want to acknowledge that there is “Accessibility Features” or “Accessibility Information” available and if the user would like to get at this information they can click a link or an image which will then provide the information that is discussed below.

I think that click a link or image should more correctly say click a text or image link. Perhaps activate a text or image link is even better.

In the current version of the UX Guide, there are no recommandations regarding the way that the following metadata should be displayed to users:

• accessibilityFeature
• accessibilityHazard
• accessMode
• accessModeSufficient

The first example in the guide simply lists these values "as-is" which doesn't feel like a good approach from a UX perspective as most of these metadata are hard to understand without additional context.

While the guide clearly states that the these metadata are meant to be machine-readable, this can be handled using JSON-LD or microdata easily and doesn't require displaying these same values as-is to users.

Since the guide recommends to implementers that these metadata should be displayed, it should also recommend IMO how they should be displayed.

For example:

• instead of just displaying tableOfContents in Accessibility Features
• we could recommend displaying "This publications contains a table of contents".

The LIA website is a good example for this, as accessibility features are clearly listed in a way that users would understand: https://catalogo.fondazionelia.org/content/later-ediz-italiana-9788892740839

We're in the process of implementing these guidelines in our various products (starting with our portal for library patrons) at De Marque and while the recommandations for the rest of the metadata are clear enough, we're a bit struggling with this remaining set of metadata.

From http://www.idpf.org/epub/a11y/techniques/techniques.html#meta-004
Do not skip reporting hazards just because an EPUB Publication does not contain any content that could present risks. Users cannot infer a meaning when no metadata is present. The value "none" can be used in such cases instead of repeating each non-hazard.

From https://www.w3.org/wiki/WebSchemas/Accessibility
All three of the negative properties should be set if none of the hazards are known to exist. If the content has hazard(s), include positive assertions for the hazards it has and negative assertions for the others.

Not sure if this discrepancy is intentional or something we missed.

From EditEUR's feedback:

NOTE (Revisions)

ONIX does not have a 1:1 mapping with EPUB or Schema.org accessibility metadata. Some accessibility assertions are made differently, and some may not currently be possible . This EPUB to ONIX crosswalk outlines the current high degree of overlap in metadata and will be updated as these two specifications evolve. It is important to note that ONIX 3.0 includes a number of new accessibility metadata codes. ONIX 2.1 can carry all the values from list 196 but has more limited accessibility metadata for other values and is not covered in this document. And not all may be carried in earlier versions of ONIX.

The two examples on
https://w3c.github.io/publ-a11y/UX-Guide-Metadata/techniques/onix.html#certifier-report

talk about 94 and 96
what about 95?

196 94 Compliance web page for detailed accessibility information
196 95 Trusted intermediary’s web page for detailed accessibility information
196 96 Publisher’s web page for detailed accessibility information (Publisher Self Certified)

What is the difference between 94 and 95 and shouldn't we explain the difference here since it looks like 95 can also be used.

From a recent discussion in the Thorium Reader issue 1332, it appears that the way to tag EPUB 3 with media overlays is unclear.

Which metadata (accessMode, accessModeSufficient) and values should an author associate with such an ebook?

From Madeleine's email: https://lists.w3.org/Archives/Public/public-epub3/2020Feb/0004.html

ONIX does not have an exact 1:1 mapping with EPUB accessibility metadata so unfortunately not all of the accessibility metadata found in an EPUB exists in ONIX at the time of this publication. There are plans to add this metadata to future versions of ONIX but no time frame has been announced. This EPUB to ONIX crosswalk outlines the current overlap in metadata which will get updated as these two specifications evolve. [add Some Schema.org metadata properties, referenced in EPUB, are descriptions of reading systems and not individual books; this means they will not be appropriate for use in ONIX and will not have a crosswalk. This includes the property "bookmarks" which indicates the ability of a reading system to allow users to set and navigate to bookmarks.] It is important to note that there were a number of new accessibility metadata codes added to ONIX 3 to support the Accessibility 1.0 specification. [delete Which means that] ONIX 2 has a limited number of accessibility metadata codes and is [delete something] not covered in this document.

Feedback from EditEUR.

https://w3c.github.io/publ-a11y/UX-Guide-Metadata/techniques/onix.html

For this page suggested new note:

NOTE (add note)

ONIX messages describe products for the global book supply chain and will be sent from publisher or creator of the epub or digital audiobook to those who will make the products available for sale, lending or subscription. These platforms may not yet have the actual files, as they may not yet be ready, or may only choose to list them for sale if they have certain accessibility features. ONIX also only describes a product, it cannot describe the features of the reading systems on which a product may be accessed. It is important to use ONIX metadata as a complement to the accessibility data embedded within the publication itself, if describing accessible books, audiobooks and related products for the global book supply chain.
An ONIX file can be used to display accessibility information in advance of publication or when you do not have access to the metadata in the digital file itself. Some accessibility information may only be available when you have access to the file itself.
If you are unfamiliar with ONIX, then there is more documentation available from EDItEUR.org.

By George Kerscher (via email)

With the Certifier Report, would this apply if it was self certified? Also, is this always a link to the actual report?

On wiki page: https://github.com/w3c/publ-a11y/wiki/Definitions-and-rationales-for-Accessibility-Metadata

ONIX techniques mentions hazards metadata but does not explicitly mention that the codes for hazards are not currently available in ONIX.

I believe the formal reference to specifications has been updated from IDPF to W3C. So, where it says:
href="http://www.idpf.org/epub/a11y/accessibility-20170105.html#wcag-a" /> should be updated to the current specification.

We are in last stages of first release of user experience guide for accessibility metadata along with techniques for ONIX and EPUB+schema.org accessibility metadata.
What should be the version for this first release.
Should we use version 1.0?

https://w3c.github.io/publ-a11y/UX-Guide-Metadata/principles/

A few questions have arisen:

• if there are two conformsTo in an EPUB, what should the platform show? (similarly it can happen for ONIX)
• if there are two accessibilitySummary (in different languages)?
• etc.

I think we have to take into account that for each metadata with cardinality 1 there could be more than one occurrence (not necessarily wrong) and tell the platforms how to behave.

From EditEUR's feedback:

Hazards

Values: flashing, motion simulation, sound, no flashing, no motion simulation, no sound, none, or Unknown.

This technique relates to Hazards principle.

Not available in ONIX
ONIX uses a composite to indicate different hazards
12 (12 means it is a hazard warning)
xx a value from list 143 to indicate the nature of a hazard or the fact that a product has been checked and does not have that particular hazard.

Example 1

The alt text description needs to be improved for the "Toggle box with all accessibility information"
That is a very general description of the image, but the image also has some accessibility features, hazards and access modes before just having …

I would recommend:

"Toggle box with all accessibility information. Showing: Accessibility Features: alternativeText, longDescriptions, printPageNumbers. Accessibility Hazards: none. AccessMode: visual, textual. …"

The following recommendation for showing accessibility conformance metadata is too specific to EPUB Accessibility:
EPUB Accessibility Conformance: WCAG-AA

This does not make this guidance document future proof. In future there can be a new publishing standard with a new name. There is also a possibility to develop the successor of EPUB Accessibility specifications, without such a close binding with EPUB 3 standards.
Therefore it is recommended to have a neutral label on left side and EPUB specific conformance information on right side for example:
Accessibility Conformance: EPUB Accessibility (WCAG AA)

This is just an example, we can improve it.

In Section 2.8.5 when the accessibilityHazard metadata is = "none" the UI should not say "None provided" because there was metadata provided.

It should say
Omit this Section
or
Hazards: none
or
Hazards: No Flashing, No Sound, No Motion Simulation.

It's not easy to understand the display documents in context unless you start from the UX guide. There are only notes in the first metadata section of each document that reference back to the UX guide, but otherwise they jump right into explaining the techniques.

It would make the documents easier to understand for people who may find them first if there were separate introductions that set up the purpose of these documents and explained their relationship with the UX guide.

A given title can have three (potentially conflicting) metadata feeds:

1. What is in the file itself
2. What is sent via ONIX
3. What is sent from the publisher independently of either of the above (typically via a spreadsheet)

We would like guidance on how to handle this.

What we currently do when viewing the metadata is you will see a11y data in three "buckets": Source file, publisher, and ONIX. These sets of data are unique, independent from each other, and can have duplicate or conflicting information. We are providing all the data we have about an asset, unaltered, so that purchasers can make informed decisions.

Our goal is to collect as much information about a title as possible. Therefore, collecting a11y data via these three buckets is summative. Updating a source file will not cause the other two buckets to empty. Sending through a spreadsheet full of onix data will not cause the publisher information to disappear, etc.

Any time one bucket is updated, that bucket will only contain the most recent information sent through. Sending a spreadsheet with abc data, then another with xyz data, will only display xyz. We will not display abcxyz.

Currently the implementations of accessibility metadata do not show anything when no accessibility metadata is available. While this spares the publisher embarrassment, it does not help to promote the need for accessibility metadata. Perhaps we should add something about this in our user experience guide. I suggest this be considered for a second release of the user experience guide.

The principles document should be independent of metadata formats and publication formats. Following this principle we have removed mention of EPUB and EPUB accessibility conformance hyperlink in definitions, but the introduction still has mention of EPUB. For example:

"Metadata found either inside an EPUB or in its corresponding ONIX file may have important accessibility information that will help end users find and determine if this EPUB can meet their specific accessibility needs."

it can be modified to:
Metadata found either inside a digital publication or in its corresponding ONIX file may have important accessibility information that will help end users find and determine if this publication can meet their specific accessibility needs.