Product metadata for born accessible content

This is the first part of a series. The second part can be found at https://booknetcanada.atlassian.net/wiki/spaces/UserDocs/pages/1260027934/Using+product+form+feature+for+born+accessible+contentThe third part can be found at https://booknetcanada.atlassian.net/wiki/spaces/UserDocs/pages/1259929698/ONIX+code+lists+and+context+for+born+accessible+content. 


What is "born accessible"?

"Born accessible" refers to building accessible books right from the beginning, and building the process into current ebook production workflows, instead of taking apart and updating books post-production to make them accessible.

How can I make my accessible ebook discoverable?

The short answer is metadata. 

Library staff need to know if your books have enhanced accessibility; retailers should display this information (and should be able to display it in advance of receiving the EPUB file); and readers and consumers should know if accessibility features are disabled as well as what is built in.

While you can supply metadata directly with the EPUB file, and it can carry information about accessibility, it's no help for anyone deciding if this ISBN represents a product that's usable for their needs. So, where do you go to provide accessibility metadata?

EDItEUR's guidelines on providing accessibility metadata in ONIX (PDF) has everything you need! Let's dive deep into what we think are the key takeaways.

  • Any EPUB-format book is accessible for many disabilities but not necessarily accessible for all. Relatively minor changes can optimize accessibility, but the needs of print-impaired readers vary and not every book can provide every option. Metadata for the ISBN should highlight which specific segment of reader the book is accessible to. 
  • Most accessibility metadata is carried in ProductFormFeature (PF-Feature) and is available in both ONIX 2.1 and 3.0 but there are some limitations in what, and how, ONIX 2.1 carries the information.
  • Most accessibility information is carried in secondary code lists. E-publication accessibility detail (PF-Feature Code "09") uses ONIX code list 196 as it's "value." Each accessibility feature is listed as its own PF-Feature code "09" entry, with each Value drawn from the Code List 196. Note that while this code list is available for use in 2.1, several codes within it are restricted to 3.0. One code (196 Code '10") can only be partially implemented in 2.1 as 3.0 offers additional support.

Product Form Feature repeats as a composite. If multiple List 196 values are required, they're delivered in separate composites. (You cannot use space delimited lists, sorry!)

  • The ONIX 2.1 EpubTypeVersion is a 10 character, free-text entry but isn't directly compatible with ONIX 3.0 which actually supports two ways to provide this information: 
  1. PF-Feature Code 10, which specifies that full version numbers be supplied but recommends use of Code 15.
  2. PF-Feature Code 15 E-publication format version code, whose values are drawn from ONIX code list 220.
  • The code list is superior because it's actually hard to get the version numbering right and accessibility features often depend on which version of EPUB is being supplied.
  • In its design of Product Form Feature, EDItEUR is making distinctions between features of an ebook (not shared by other books) such as:
    • navigation capabilities, 
    • textual descriptions of illustrations & graphic information, and
    • use of typographical design to help dyslexic readers.
  • EDItEUR is also making distinctions between features ONIX cannot describe, such as reading system functionality shared by most ebooks, i.e., text re-sizing and text-to-speech functionality. These features are often dependent on the EPUB version and that's why its support is emphasized.

What else do I need to do?

Retailers should (must is more appropriate) display this information, as it's needed by consumers. It's also important that the metadata is made available to libraries and other institutions.

Keep accessibility features enabled! Don't disable them either deliberately or inadvertently. It's important to code that "this book is fundamentally inaccessible" if it is true, especially if you're disabling accessibility support intentionally. Be clear upfront so readers and consumers can get to the right book. 

Questions, comments, problems, or just need some reassurance?  Contact biblio@booknetcanada.ca.



This originally appeared on the BNC Blog at https://www.booknetcanada.ca/blog/2019/6/20/producing-born-accessible-books. Subscribe the the blog RSS at https://www.booknetcanada.ca/blog?format=rss.