ONIX List 81 Code 10 and Accessibility Metadata

[rickj]

We’ve encountered an implementation issue in how ONIX List 81 code 10 (“Textual”) is being interpreted under the Accessibility Metadata Display Guide for Digital Publications 2.0.

Observed Behavior

In current practice, code 10 is often assigned automatically by aggregators or conversion pipelines—particularly when ONIX 2.x feeds are converted to ONIX 3.x. The code is intended as a simple descriptor of the primary content type (i.e., the title is primarily textual), but in the Display Guide’s interpretation, it is being treated as a positive accessibility claim.

This has led to downstream consequences for data consumers, including VitalSource. In our system, ONIX accessibility metadata takes precedence over EPUB schema.org metadata. When code 10 appears, it supplants valid EPUB accessibility information, resulting in suppression of accurate accessibility metadata and, in some cases, the appearance of an unintended accessibility conformance claim.

Real-World Impact

Because this assignment is happening automatically in ONIX aggregation and conversion processes, many publishers are unaware that they are inadvertently signaling accessibility conformance. The outcome is confusing both for metadata consumers and for end users who rely on accurate accessibility indicators.

Request

We’d like to propose a clarification or change in the specification to prevent List 81 code 10 from being interpreted as an accessibility claim when it is the only code present or when it is clearly serving as a content-type descriptor rather than an accessibility assertion.

This could take the form of:
• Explicit guidance in the Display Guide noting that code 10 alone should not be treated as an accessibility conformance statement, or
• An adjustment to the interpretation hierarchy so that “Textual” functions as a neutral descriptor rather than a claim.

Next Steps

We’re implementing a system-level enhancement to ignore code 10 when it is the only ONIX accessibility code received, but we believe a standards-level clarification would help prevent similar issues across the ecosystem—especially as ONIX 2.x–to–3.x conversions are widespread.

We’d be happy to share data examples and discuss how this interpretation could be refined to reduce unintentional conformance signaling while preserving the Guide’s intent.

[rickj]

some impact numbers: over 60% of EPUB files with schema.org accessibility claims in our system have a corresponding ONIX claim for list 81 code 10 that is the ONLY ONIX claim... thus blocking all of the schema.org claims.

[mattgarrish]

@rickj What output are you getting from the code?

The only use I can find for code 10 in list 81 is that it used to set the real_text variable. That in turn only ever generates the statement: "Not fully readable in read aloud or dynamic braille" if all_necessary_text_content isn't true. That doesn't sound contradictory to what you're saying about these books, that they are primarily text, or are you asking to say nothing at all?

The more positive statement about being readable in read aloud or as refreshable braille comes from all_necessary_text_content which corresponds to code 52 in list 196.

[rickj]

It appears that (for some) it is standard procedure (especially when converting ONIX 2.x to 3.x) to declare code 10 as a default (because... in actuality... it is primarily text!). The problem is that this seems to happen when establishing non-a11y ONIX metadata (again... because it is primarily text!). Because this is also a11y metadata (generating the "Not fully readable in read aloud or dynamic braille" messaging) we have a situation where teams establishing non-a11y metadata have created a single a11y metadata claim.

Our issue is that they are not (at this time) creating additional ONIX a11y claims... so this one is standing alone as the ONLY ONIX a11y claim. We cannot make a judgement of which set of claims are true... the schema.org ones, or the ONIX ones. To avoid this we established a priority where the default is what is in the EPUB, which can be replaced by ONIX claims (which can also be replaced by direct upload to us). This enables publishers to manage any metadata updates without having to re-upload the EPUB file itself.

What we are doing to counter this (overwhelming large amount of cases) from affecting what the end user sees is to ignore List 81 Code 10 if it is the ONLY a11y claim. We think, given the dual nature of this code, this should be considered in the recommendations of the guide.

[mattgarrish]

Ah, okay, I understand now. Yes, since it's being interpreted from non-accessibility metadata in onix, unlike the way accessMode and accessModeSufficient are used in the epub techniques, there's no guarantee it's being set intentionally, even outside of this case of automatic translation.

It could also be the case that the full text is readable but because no other accessibility metadata is being claimed we really don't know for sure, so saying it "is not fully readable" could be misleading, too.

I'm not sure what a less definitive statement would read like, though. Something like: "Has text content but no claim made about readability in read aloud or as refreshable braille"?

[rickj]

I believe the short term 'fix' is not to change the statement, as it would be appropriate when accompanied by other claims. Rather we should recommend that if it is the ONLY claim in ONIX to not use it as an a11y claim.

[mattgarrish]

as it would be appropriate when accompanied by other claims

It would, yes, but are people adding accessibility metadata when they fail conformance, because that would seemingly have to be the case for it to be used legitimately? You can't meet level A conformance without a book having a full textual sufficient access mode, but that's captured in the first statement. This statement only captures non-conforming content (sub level A) with some text content.

(Does the EAA push people to add metadata even if they claim an exemption for non-conformance, for example?)

that if it is the ONLY claim in ONIX to not use it as an a11y claim

That begs the question of what constitutes a claim? Is it enough to just check if any value from code list 196 is set, which shouldn't be too hard, or does all the other metadata we inspect need to be checked, too? (e.g., hazards)

[rickj]

@mattgarrish I understand your questions, however, I'm not trying to explain why people are doing things, only to highlight what we are being forced to react to (with 91% of our EPUB's!).

[mattgarrish]

Right, I'm just trying to figure out what we can even do here. What I'm getting from the issue are:

• the algorithm is working as expected - the purpose of checking 81-10 without other metadata is so that all the epubs without any explicitly authored accessibility metadata can still be identified as at least largely usable by assistive technologies;
• stating that the presence of 81-10 means a publication is not fully readable is not true - we don't know how much is readable, could be some, could be all;
• if we're inferring metadata, the epub techniques should probably have a similar test to output the same string if accessMode and accessModeSufficient are not set and rendition:layout is not set or is set to reflowable - this is the equivalent "largely text but we don't know how much" test for the package document since reflowable epubs are not image-only.

You can also suppress the metadata if that's your preference - these are guidelines, after all, and this is the only inferred statement

But there's an editor's call this Thursday that will include this issue, so these are just the questions I'll have.