ONIX accessibility metadata tells retailers, libraries, distributors, and readers which accessibility features an individual digital publication actually provides. In ONIX 3, publishers express these details through repeatable <ProductFormFeature> composites: feature type 09 points to accessibility values from EDItEUR List 196. The European Accessibility Act (EAA) has applied since 28 June 2025 and includes accessibility requirements for ebooks and related services, making accurate product metadata operationally important as well as useful for discovery. If you already send ONIX 3, validate an accessibility-enabled file now while you work through this guide.
This article explains the metadata workflow, not legal compliance. Applicability, exceptions, and national enforcement can vary, so confirm legal obligations with qualified counsel and the relevant authority.
What ONIX accessibility metadata does
Accessibility metadata describes a product; it does not make the underlying EPUB or PDF accessible. The production team must first build and test the file, then the metadata team must encode verified facts about that exact product. Receivers can use those facts to display accessibility information or support search and filtering.
Examples include whether the publication has a logical reading order, alternative text for non-text content, structural navigation, page-list navigation, accessible math, synchronized audio and text, or compatibility with non-visual reading. List 196 also supports accessibility summaries, conformance claims, certification details, assessment dates, and contact information.
The European Commission explains that covered ebooks must be discoverable through metadata about their accessibility features. ONIX is the book supply chain’s structured way to transmit those details, but it is not the law itself and validation is not a compliance certificate.
Why ONIX 3 is required for detailed accessibility data
ONIX 2.1 cannot carry the modern structured values in List 196. EDItEUR marks the list for use only with ONIX 3.0 or later, and 2.1 is now obsolete. Publishers that still export 2.1 should treat migration to ONIX 3 as a prerequisite for sending detailed accessibility metadata through ONIX.
How List 79 and List 196 work together
Within <DescriptiveDetail>, repeat <ProductFormFeature> for each applicable accessibility statement. <ProductFormFeatureType> uses code 09, meaning “E-publication accessibility detail.” <ProductFormFeatureValue> then uses a value from List 196.
<ProductFormFeature>
<ProductFormFeatureType>09</ProductFormFeatureType>
<ProductFormFeatureValue>13</ProductFormFeatureValue>
</ProductFormFeature>In the current EDItEUR list, value 13 means the publication has a single logical reading order. This example demonstrates structure only. Do not add the value unless the specific ebook has been checked and genuinely meets the definition.
Use additional repeats for other verified features. Where a List 196 entry calls for explanatory text, a date, a contact, or a URL, supply it in <ProductFormFeatureDescription> exactly as the code-list notes specify. Do not treat free text as a substitute for the full structured feature set.
Build a reliable accessibility metadata workflow
1. Assess the actual publication file
Test the delivered EPUB or PDF, not a manuscript or production checklist. Confirm reading order, headings, table of contents, page navigation, alternative descriptions, links, forms, media alternatives, display flexibility, and assistive-technology behavior as applicable. Record which version of the file was assessed.
2. Store evidence with product metadata
For each identifier and format, retain the assessment result, standard and version, date, supporting report, limitations, and a contact. Product-level storage prevents a reflowable EPUB’s claims from being copied to a fixed-layout PDF.
3. Map facts to current codes
Select List 196 values by reading their full definitions and usage notes, not just their short labels. Some values describe features, others describe conformance, certification, known limitations, or exceptions. Record the code-list issue used by the export so future updates can be reviewed deliberately.
4. Generate repeatable ONIX composites
Output one correctly ordered <ProductFormFeature> composite per claim. Keep the summary consistent with the granular codes, include limitations, and add any description or URL required by the selected code.
5. Validate structure and meaning separately
Schema and code-list validation can catch malformed XML, wrong order, missing companion elements, and invalid values. It cannot inspect an ebook and prove that images have useful descriptions or that reading order is logical. Pair automated validation with a human or specialist review of the publication and its evidence.
6. Reassess after material changes
A new EPUB export, remediation pass, DRM configuration, added interactive feature, or replacement PDF may change the accessibility profile. Link metadata review to the release process and update the assessment date when a new check is completed.
Common accessibility metadata mistakes
- Leaving the feature set empty. A structurally valid ONIX 3 record may still give receivers no usable accessibility information.
- Claiming features from the template. A production template may support accessibility, but the shipped file still needs assessment.
- Copying across formats. EPUB, PDF, audiobook, and fixed-layout products often have different features and limitations.
- Using labels as definitions. A familiar-sounding List 196 label may have narrower usage notes than expected.
- Relying on a free-text note alone. Structured codes are more interoperable; summaries and addenda should complement them.
- Treating validation as certification. A validator checks the ONIX message, not the accessibility of the ebook itself.
- Forgetting change control. Correct metadata becomes stale when the underlying file changes.
Accessibility metadata validation checklist
Before sending the feed, verify that:
- The message is ONIX 3.0 or 3.1 and validates against the matching schema.
- Every accessibility composite uses
<ProductFormFeatureType>09</ProductFormFeatureType>. - Every value exists in the current List 196 and its usage notes have been followed.
- Required descriptions, dates, URLs, or contact details accompany the relevant values.
- The summary agrees with granular features and acknowledges meaningful limitations.
- Claims apply to the product identifier and format in that record.
- Evidence comes from the final publication file or a controlled equivalent.
- A person responsible for accessibility data has reviewed the export.
- The file is revalidated after corrections.
For help reading structural findings, see our guide to common ONIX 3 validation errors. If your broader metadata workflow needs review, the book metadata checker guide explains what automated checks can and cannot establish.
Frequently asked questions
Is ONIX metadata alone enough for EAA compliance?
No. Metadata communicates verified accessibility information, while the ebook, reading experience, service, documentation, and organizational process may all matter. Requirements and exceptions depend on the applicable law and context.
Which ONIX code list contains accessibility features?
Use Product Form Feature Type 09 from List 79, then choose the corresponding Product Form Feature Value from List 196. Always use the current definitions and notes published by EDItEUR.
Authoritative references
Consult the European Commission’s overview of the EAA entering into application, EDItEUR List 79 for Product Form Feature Type, and the current List 196 accessibility values when designing and maintaining your workflow.