Bringing up the topic of metadata usually triggers thoughts about the need to include title and author information in an ebook. While certainly a necessity, this kind of traditional metadata is not what we’re going to delve into now.
One of the big issues facing people with disabilities as they try to enter the ebook market is how to discover the quality of the ebooks they want to buy. One ebook is not the same as another, as we’ve been discussing, and readers need to know what they’re getting when they pay for your product. And you should be rewarded for your commitment to accessibility by having your ebooks stand out from the crowd.
Unfortunately, in the past, once you pushed your ebook into a distribution channel, whatever good work you had done to make your content accessible would become indistinguishable from all the inaccessible content out there to the person on the purchasing end. At about the same time that EPUB 3 was being finalized, however, the people at EDItEUR introduced a new set of accessibility metadata for use in ONIX records. This metadata plugs the information gap.
An ONIX record, if you’re not familiar, is an industry-standard message (xml record) that accompanies your publication, providing distributors with both content and distribution metadata. This information is typically used to market and sell your ebook, and these new properties now allow you to enhance that information with the accessible features your ebook includes. Retailers can then make this information available in the product description, for example, so readers can determine whether the ebook will adequately meet their needs. It’s also not a stretch to imagine this information being integrated into bookstore search engines to allow readers to narrow their results based on their needs.
To include accessibility metadata in your ONIX record, you use the ProductFormFeature element, which is described in the
standard as a composite container for product information (e.g., it is also used to
provide product safety information). To identify that the element contains
accessibility information, it must include a ProductFormFeatureType child element with the value 09, as in the following example:
<ProductFormFeature>
<ProductFormFeatureType>09</ProductFormFeatureType>
…
</ProductFormFeature>
When this value is encountered, it indicates that the value of the sibling ProductFormFeatureValue element is drawn from ONIX for Books codelist 196, which defines the new accessible
properties and the values to use in identifying them. As of writing, this codelist
includes the following properties:
No reading system accessibility options disabled (10)
Table of contents navigation (11)
Index navigation (12)
Reading order (13)
Short alternative descriptions (14)
Full alternative descriptions (15)
Visualised data also available as non-graphical data (16)
Accessible math content (17)
Accessible chem content (18)
Print-equivalent page numbering (19)
Synchronised pre-recorded audio (20)
So, for example, if our EPUB contains accessible math formulas (using MathML) we would indicate it as follows:
<ProductFormFeature>
<ProductFormFeatureType>09</ProductFormFeatureType>
<ProductFormFeatureValue>17</ProductFormFeatureValue>
</ProductFormFeature>
Likewise, to indicate accessible chemistry content (using ChemML) we would use the
value 18:
<ProductFormFeature>
<ProductFormFeatureType>09</ProductFormFeatureType>
<ProductFormFeatureValue>18</ProductFormFeatureValue>
</ProductFormFeature>
You must repeat the ProductFormFeature element for each
accessibility requirement your EPUB meets; it is not valid to combine all your
features into a single element.
You must also ensure that you make yourself familiar with the requirements for compliance before adding any accessibility properties; each of the properties defined in codelist 196 includes conformance criteria. EPUB requires table of contents navigation, for example, but the addition of the required navigation document does not automatically indicate compliance. You need to include full navigation, plus navigation to any tables and figures, before you comply with the table of contents navigation requirement. Likewise, all EPUBs have a reading order defined by the spine element in the package document, but that does not mean you comply to including a reading order. You need to ensure that sidebars and footnotes and similar information has been properly marked up so as not to interfere with the narrative flow, as we went over in the section on the logical reading order.
It is additionally worth noting that there are three properties that aren’t directly related to the content of your EPUB:
Compatibility tested (97)
Trusted intermediary contact (98)
Publisher contact for further accessibility information (99)
Each of these properties requires the addition of a child ProductFormFeatureDescription element to describe compliance:
<ProductFormFeature>
<ProductFormFeatureType>09</ProductFormFeatureType>
<ProductFormFeatureValue>97</ProductFormFeatureValue>
<ProductFormFeatureDescription>
Content has been tested to work on iBooks, Sony Reader and Adobe Digital
Editions in both scripting enabled and disabled modes.
</ProductFormFeatureDescription>
</ProductFormFeature>
Whatever compatibility testing you’ve performed should be listed using code 97 so that readers can better determine the suitability of your ebook for their purposes. Not all reading systems and assistive technologies work alike, or interact well together, and real-world testing is the only way to tell what does and does not work.
There are organizations who specialize in testing across a broad spectrum of devices who can assist you in evaluating your content, as this kind of evaluation can be no small undertaking. A good practice to develop, for example, might be to periodically have typical examples of content coming out of your production stream tested for compatibility issues. The resulting statement could then be re-used across much of your content, so long as the features and markup used remain consistent.
Once you start getting creative with your content (e.g., using extensive scripted interactivity), you should engage experts as early on in the process as you can to ensure any statement you make remains true, however.
The other two codes provide contact information for the person(s) in your organization, or at a trusted intermediary, who can provide additional accessibility information:
<ProductFormFeature>
<ProductFormFeatureType>09</ProductFormFeatureType>
<ProductFormFeatureValue>99</ProductFormFeatureValue>
<ProductFormFeatureDescription>
accessibility-officer@example.com
</ProductFormFeatureDescription>
</ProductFormFeature>
If you’re providing educational materials, for example, you’ll want to provide educators a way to be able to contact you to determine whether your content will be accessible by students with various needs that may not be specifically addressed in your compatibility testing statement or in the available metadata properties.