Explain the absence of metadata

[mattgarrish]

It might help to add a section to the introduction about how to interpret a page/EPUB without metadata.

For example, if no accessibility metadata is specified, then you should assume the page has never been assessed. But if some metadata is found, you should assume that unspecified values indicate the feature/mode/etc. isn't present (although there's always the chance the publisher missed them).

[nekennedy]

I'm concerned that this would lead to an all-or-nothing approach to accessibility, rather than incremental improvements to the accessibility of files and metadata (both for updating backlist and for frontlist process improvements). Mapping these to negative values rather than unknown ones may prevent people from including any accessibility metadata at all (especially the potential legal implications if the lack of dcterms:conformsTo maps to "does not meet WCAG A" rather than "may not meet WCAG A").

Another issue would be changing accessibilityFeature requirements. I don't think the presence of printPageNumbers but missing pageNavigation and pageBreakMarkers should specify that there is no page-list or doc-pagebreaks.

Example: As someone dealing with remediating a huge backlist, I can parse epub files automatically for a limited set of accessibilityFeatures:

• A complete navdoc/ncx has been a part of our reflow process for more than a decade, I can consistently add tableOfContents to all files produced after X date by X workflow. I can also add pageNavigation and pageBreakMarkers based on the legacy printPageNumbers feature and an analysis of the navdoc (and for older titles, I can convert the EPUB2 ncx pageList element to an EPUB3 page-list and add the corresponding features).
• I cannot automatically add highContrastDisplay or displayTransformability (or more importantly, dcterms:conformsTo) which need to wait until someone qualified has time to look through the book and confirm there are no issues.

I would like to distribute updated files with automatically-detected accessibilityFeatures as quickly as possible, leaving the more manual step for a later date. If we say "missing is an explicit no" I may hang on to these incrementally improved files (many of which are probably at least WCAG-A with the automated fixes) until the manual step can be completed.

[mattgarrish]

I wasn't intending that we would make a hard no statement that missing metadata means features, etc. cannot be present. But I think it's helpful to state that if it's missing, users will have to work on the assumption that it's not available. (In the case of metadata that hasn't been thoroughly checked, that's probably something you should be saying in the summary so users can make a more informed decision.)

I'm also not suggesting that we port this over to the epub display metadata stuff and have explicit reporting of all values that haven't been set. That would definitely be a step too far, and I don't think it's helpful to list off everything that probably isn't available.

This could be phrased for authors so they understand that if they don't set the metadata, user agents/users can't be expected to infer it for them, and there are dangers if they try. To push for more complete reporting, in other words.

[nekennedy]

We were discussing the UI display of metadata this morning, and so I read the "you" in the initial comment as being the retailer/reading system. My apologies!

I think the user assuming that a feature they need is missing based on the lack of provided metadata is accurate, and emphasizing in the documentation for authors that users need to make this assumption would be helpful.

I'm not sure I agree that if partial metadata is present the user assumes something different than if no metadata is present. I think it would push for more complete reporting for some publishers, but the result may be other more reluctant publishers do not include anything at all. I guess we are back to the point where each feature needs 4 values (yes/missing from file/not applicable/unknown). In the meantime, if we give users guidance about what to assume from missing data and we want to push publishers for more complete data I think it should be 'assume not present' all the time (rather than 'assume not present' if anything is declared and 'everything is unknown' when all accessibility metadata is missing).

(yes, there is something generic in our summary)

[mattgarrish]

No worries, it's not even a fully developed idea in my head at this point.

It came up in unrelated discussions about how to interpret the absence of a feature. It may be that we should advise authors on the consequences of leaving out information (lack of searchability, misunderstandings in display metadata, etc.) and stop at that. Nowhere do we require that every feature be listed, but the less information you give the more users are likely to form the wrong opinion of the value to them.