This proposal comes from the digital publishing community, and specifically from the Epub 3.1 Accessibility Working Group (with support from the whole Epub 3.1 group).

This proposal addresses use cases in digital publishing for accessible ebooks for which current metadata is not sufficient. These use cases require distinguishing between an ebook which has the complete text and audio of the work, one with the complete text and partial audio, and one with the complete audio and partial text. Additional permutations of this sort arise as multimedia in ebooks is factored in, requiring an access mode-based solution rather than a vocabulary of types of books.

Like the existing accessibility properties, these new properties can apply to any CreativeWork. They might apply to physical books in some cases (particularly braille books and audio books on physical media) but this work is probably separate from the bibliographic extension.

We are proposing three properties:
accessMode: The human sensory perceptual system or cognitive faculty through which a person may process or perceive information.

accessModeSufficient: A list of single or combined accessModes that are sufficient to understand all the intellectual content of a resource.

accessibilitySummary: A human-readable summary of specific accessibility features or deficiencies, consistent with the other accessibility metadata but expressing subtleties such as "short descriptions are present but long descriptions will be needed for non-visual users" or "short descriptions are present and no long descriptions are needed."

accessMode is important for defining the basic contents of a file. Is this an ebook with audio or plain text? Are there visuals? Having this information allows a more personalized search process because tools can support users who are looking for materials that meet their needs with or without accessibilityFeatures.

accessModeSufficient is important for distinguishing the various ebook types described above. The use cases in our proposal show in detail why this is necessary to permit fine-grained description of accessible ebooks. It permits a metadata author to be specific about what combinations of access modes will give full access to a resource. Some metadata authors may not wish to author this property; they will still be able to make use of accessMode, which is simpler. Publishers working intensively on accessible ebooks will be motivated to understand and use both properties.

accessModeSufficient may also be useful to search engines seeking to filter resources for users. In some cases, it serves as an encoding of the combination of accessModes and accessibilityFeatures, revealing, for example, that a silent video is accessible even though it lacks captions, because there is no audio to be captioned, or that a web page that has images is accessible to a non-visual user because the images have been described.

accessibilitySummary offers a backup for subtle information that is hard to communicate with structured metadata but might be important to readers searching for a suitable ebook or other resource.

These properties are suitable for non-ebook use as well. Any multimedia resource can be better described with these properties.

The proposal is detailed at the following page, including use cases:
https://github.com/daisy/epub-revision-a11y/wiki/ePub-3.1-Accessibility--Proposal-To-Schema.org

Thanks for the detailed proposal. I have made a pass at implementing it for wider review and discussion.

Draft available at:

• http://pending.webschemas.org/accessMode
• http://pending.webschemas.org/accessibilitySummary
• http://pending.webschemas.org/accessModeSufficient

In putting this together the most obvious question to ask was about the values of these properties. Schema.org has the notion of an Enumeration, which allows us to define natural-language-neutral URLs for well known property values (e.g. http://schema.org/True). Our previous accessibility-related properties e.g. http://schema.org/accessibilityFeature haven't yet used this construct and instead documented rough lists of possible values in a Wiki. I have for now followed that approach here, and have made a JSON-LD example which shows repeated use of a property for multiple values. This will look somewhat more verbose in RDFa/Microdata. Was this approach your intention or should we look to define more rigid enumerations for accessMode and accessibilitySummary? /cc @betehess who has been investigating the tradeoffs around strings vs enumerated URLs for opening hours ("Monday" vs http://schema.org/Monday etc.).

<script type="application/ld+json">
{
  "@context": "http://schema.org/",
  "@type": "Book",
  "name": "Some graphic novel",
  "accessMode": ["textual", "visual"],
  "accessModeSufficient": ["textual", "visual"],
  "accessibilitySummary": "Visual elements are not described."
}
</script>

Also: accessibilitySummary ... can we think through whether this broadly-named property could also serve a purpose for real world / physical accessibility eg. of places? We have discussed such functionality previously (#254).

/cc @chaals @vholland @rvguha @pmika @scor @shankarnat @tmarshbing

So interpreting what the array means is where I got stuck. In your example, you need all the modes. But many resources have multiple sets of accessModeSufficient. So given a movie which requires either audio, or visual+text, to be usable, does something like the following work?

<script type="application/ld+json">
{
  "@context": "http://schema.org/",
  "@type": "Movie",
  "name": "Some graphic novel",
  "accessMode": ["textual", "visual"],
  "accessModeSufficient": ["textual", "visual"]
  "accessModeSufficient": ["audio"],
  "accessibilitySummary": "There is audio description, and closed captioning of the main audio"
}
</script>

Also: accessibilitySummary ... can we think through whether this broadly-named property could also serve a purpose for real world / physical accessibility eg. of places? We have discussed such functionality previously (#254).

Yes, it wouldn't be a bad start.

Charles,
You are interpreting the array of accessModeSufficient values correctly. The intent is that user must be able to use all of the modes in any one line together to fully use the resource, but in some cases there are several distinct combinations that are sufficient, each with their own accessModeSufficient statement. Your movie example works perfectly. It would make sense to add

"accessibilityFeature": ["audioDescription", "captions"]

Use of accessibilitySummary for general description of accessible places makes sense. We would need to edit the definition, and I would suggest adding a warning that if structured metadata fields are available, they should be used instead of or in addition to a plain-text summary. If summary is the only field adopted widely, we will have less functionality than if accessMode and accessibilityFeature are adopted widely.

@madeleinerothberg yes it makes sense to add the accessibilityFeatures.

@danbri does my syntax give the right structure? I've got a head full of 'flu, but it strikes me that there should be a node in the middle, so the resulting data doesn't look like

resource -> accessModeSufficient -> (the two arrays, merged).

?

Ah, yes it sounds like some substructure is needed then.

Also I think related to @chaals' point: there's a convention that we try to stick to which is that the meaning of one property/value pair ought not to be undermined by a nearby additional property/value pair, to avoid confusion if the data is subsetted. I don't think we always stick to it though. Sorry that isn't the most helpful explanation, I'll try to work through an example asap.

Yes, we need some way for each accessModeSufficient statement to remain separate. I wouldn't say that one statement "undermines" the next; each one adds more data about the resource being described without changing the truthfulness of the previous statements. But that might be different than your intended meaning for undermined.

I think we should move forward on accessibilitySummary while we figure out how to get the model right for the other two. It would indeed be a very valuable property to describe places and products.

@madeleinerothberg - yes, I was trying to say that we want an additive design as you outline

I'd be happy to move forward with accessibilitySummary and accessMode (which does not require complicated modeling), but let's not delay figuring out the model for accessModeSufficient. Having summary without the others would encourage use of less structured data when more structure is ultimately going to provide better results. The EPUB community is also eager to get this metadata in place and is moving toward a version 3.1. How can we work this out? Would a synchronous call for interested participants be helpful?

With Schema 3.0 launched, I'd like to see these accessibility proposals included in the next release. What is necessary to do that?