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?

Per email exchange, let's try to have a call with @chaals and any other interested parties in early-mid June.

{
  "@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"
}

parses to

_:b0 http://schema.org/accessMode "textual" .
_:b0 http://schema.org/accessMode "visual" .
_:b0 http://schema.org/accessModeSufficient "audio" .
_:b0 http://schema.org/accessibilitySummary "There is audio description, and closed captioning of the main audio" .
_:b0 http://schema.org/name "Some graphic novel" .
_:b0 http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://schema.org/Movie .

rough example attempt

{
"@context": "http://schema.org/",
"@type": "Movie",
"name": "Some graphic novel",
"accessMode": ["textual", "visual"],
"accessModeSufficient": { "@list": ["textual", "visual"] },
"accessModeSufficient": { "@list": ["audio"] },
"accessibilitySummary": "There is audio description, and closed captioning of the main audio"
}

but I don't see what I expect in http://json-ld.org/playground/ per https://www.w3.org/TR/json-ld/#sets-and-lists

AHA

this.

{
  "@context": "http://schema.org/",
  "@type": "Movie",
  "name": "Some graphic novel",
  "accessMode": ["textual", "visual"],
  "accessModeSufficient": [ { "@list": ["textual", "visual"] }, { "@list": ["audio"] } ],
  "accessibilitySummary": "There is audio description, and closed captioning of the main audio"
}

_:b0 http://schema.org/accessMode "textual" .
_:b0 http://schema.org/accessMode "visual" .
_:b0 http://schema.org/accessModeSufficient _:b1 .
_:b0 http://schema.org/accessModeSufficient _:b3 .
_:b0 http://schema.org/accessibilitySummary "There is audio description, and closed captioning of the main audio" .
_:b0 http://schema.org/name "Some graphic novel" .
_:b0 http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://schema.org/Movie .
_:b1 http://www.w3.org/1999/02/22-rdf-syntax-ns#first "textual" .
_:b1 http://www.w3.org/1999/02/22-rdf-syntax-ns#rest _:b2 .
_:b2 http://www.w3.org/1999/02/22-rdf-syntax-ns#first "visual" .
_:b2 http://www.w3.org/1999/02/22-rdf-syntax-ns#rest http://www.w3.org/1999/02/22-rdf-syntax-ns#nil .
_:b3 http://www.w3.org/1999/02/22-rdf-syntax-ns#first "audio" .
_:b3 http://www.w3.org/1999/02/22-rdf-syntax-ns#rest http://www.w3.org/1999/02/22-rdf-syntax-ns#nil .

Alternative would be to use http://schema.org/ItemList

Here is an alternative formulation that does not use RDF (ie. JSON-LD + RDFa friendly) lists, but instead uses the ListItem construction we have within schema.org:

{
  "@context": "http://schema.org/",
  "@type": "Movie",
  "name": "Some graphic novel",
  "accessMode": ["textual", "visual"],
  "accessModeSufficient": [ 
       { "@typeof": "ListItem", "itemListElement": ["textual", "visual"] }, 
       { "@typeof": "ListItem", "itemListElement": ["audio"] } ],
  "accessibilitySummary": "There is audio description, and closed captioning of the main audio"
}

The triples view from JSON-LD parser (the Playground tool again) is:

_:b0 http://schema.org/accessMode "textual" .
_:b0 http://schema.org/accessMode "visual" .
_:b0 http://schema.org/accessModeSufficient _:b1 .
_:b0 http://schema.org/accessModeSufficient _:b2 .
_:b0 http://schema.org/accessibilitySummary "There is audio description, and closed captioning of the main audio" .
_:b0 http://schema.org/name "Some graphic novel" .
_:b0 http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://schema.org/Movie .
_:b1 http://schema.org/@typeof "ListItem" .
_:b1 http://schema.org/itemListElement "textual" .
_:b1 http://schema.org/itemListElement "visual" .
_:b2 http://schema.org/@typeof "ListItem" .
_:b2 http://schema.org/itemListElement "audio" .

Tradeoff is that this design is syntax-neutral and works equally well or badly in Microdata. In doing so it opts out of the syntax-level support in JSON-LD (via "@list") and in RDFa 1.1 (via @inlist ).

https://www.w3.org/TR/rdfa-syntax/#list-generation

Q: to what extent could these concepts be applied to description of Events?

FWIW I don't think that modelling things as untyped lists of lists is very human-friendly, or in fact good modelling. Doubly so as none of the lists in question are in fact ordered, which means they aren't really lists... Semantically, this is saying that ["textual", "visual"] is a different requirement from ["visual", "textual"] — I don't think that's true.

At this point we're really better off having a new class, says AccessModality. This has the added advantage that you can also attach a useful description to it, an indication of how to access a given modality. The modalities on one AccessModality are anded; several AccessModalitys can be specified and those are ored.

{
  "@context": "http://schema.org/",
  "@type": "Movie",
  "name": "Some graphic novel",
  "accessMode": ["textual", "visual"],
  "accessModeSufficient": [ 
    {
      "@type": "AccessModality",
      "requiredModality": ["textual", "visual"],
      "name": "Closed-captioning"
    },
    {
      "@type": "AccessModality",
      "requiredModality": ["audio"],
      "description": "Audio description",
      "url": "http://berjon.com/singing-some-beyonce.mp3"
    }
  ]
}

This might further obviate the need for accessibilitySummary since the modalities can describe that. It could also be more oriented towards universal design (rather than just a11y) and be used to specify other aspects (eg. requires a touch device, a colour screen…)

Your approach sounds interesting, will be interested to hear what others think. This approach would not replace the need for accessibilitySummary as this can be used outside of accessModeSufficient for other accessibility descriptions needed in other disciplines other than Digital Publishing.

@darobin. - the motivation for a list is that it becomes harder to accidentally subset the data, casually altering its semantics quite strongly. The encoding of OWL rules in RDF/S exploited similar structures. It ain't pretty, for sure, but when what you want to say doesn't really partition into independent triples the options are awkward.

Writing existing use cases in the syntax DanBri proposed, we get these examples. Comments and corrections welcome.

Use case 2.B from:
https://github.com/daisy/epub-revision-a11y/wiki/ePub-3.1-Accessibility--Proposal-To-Schema.org

"Alice in Wonderland" – Children's book with illustrations
A novel for children, with complementary illustrations.
Case 2.B - audio media overlays for the text of the story, short descriptions of illustrations.

According to syntax in:
#1100 (comment)

{
  "@context": "http://schema.org/",
  "@type": "Book",
  "name": "Alice in Wonderland",
  "accessMode": ["auditory", "textual", "visual"],
  "accessibilityFeature": ["alternativeText", "synchronizedAudioText"],
  "accessModeSufficient": [ { "@list": ["textual"] }, { "@list": ["textual", "visual"] }, { "@list": [“auditory"] }, { "@list": ["auditory", "visual"] }, { "@list": ["auditory", "visual"] }, { "@list": ["auditory", "visual", "textual"] } ],
  "accessibilitySummary": "Short descriptions are provided; long descriptions of the images are not needed for most readers."
}

If instead we use the syntax in:
#1100 (comment)

{
  "@context": "http://schema.org/",
  "@type": “Book",
  "name": "Alice in Wonderland",
  "accessMode": ["auditory", "textual", "visual"],
  "accessibilityFeature": ["alternativeText", "synchronizedAudioText"],
  "accessModeSufficient": [ 
       { "@typeof": "ListItem", "itemListElement": ["textual"] }, 
       { "@typeof": "ListItem", "itemListElement": ["textual", "visual"] }, 
       { "@typeof": "ListItem", "itemListElement": ["auditory"] }, 
       { "@typeof": "ListItem", "itemListElement": ["auditory", "visual"] }, 
       { "@typeof": "ListItem", "itemListElement": ["auditory", "textual"] }, 
       { "@typeof": "ListItem", "itemListElement": ["auditory", "textual", "visual"] } ],
  "accessibilitySummary": "Short descriptions are provided; long descriptions of the images are not needed for most readers."
}

@danbri That can support the case for @list (though I would contend it is a case for @set) in the branches, but not a case for lists of lists.

Also I'm not sure about the "accidentally subset data" problem; I mean this could happen at any time, and is very dependent on how you process the data. We can't be defensive against all such arbitrary cases, unless we start hashing, no?

@chaals, @danbri, does @set make sense? @darobin is correct that the items in the groups (and the groups themselves) do not require a specific order. What is the best way to model this aspect?

@set is a W3C JSON-LD issue: https://www.w3.org/TR/json-ld/
Is there order in set? I was not aware of that.

All of these decisions look fine to me except that I would argue to keep "colorDependent" in the accessMode vocabulary. It is used to flag material which would be difficult to use for someone with color blindness, which is one of the more common visual impairments.

In addition, I would argue to keep textOnVisual, which has been a feature of access mode going back several iterations in IMS (with the name textOnImage). Again, this is a common problem for accessibility, when text is included in an image and cannot be adjusted visually or read aloud by TTS.

The proposal to add accessMode and its vocabulary doesn't currently include definitions for each term, but as part of this process we will create documentation that includes those definitions and any other materials that the community would like. Would that help alleviate the concerns about these terms?

@madeleinerothberg can you point us to definitions for these. Currently the draft definitions are just a list of mysterious (to the uninitiated...) strings. Is there an URL elsewhere that e.g. 'textOnVisual' should link to, or a short phrase defining it?

ColorDependent and textOnImage are both defined in the IMS Access for All v3 public draft in the Data Element Specification document, linked below. We can use these short definitions or improve them, as seems best to this community. We will post additional definitions so that all terms in the schema vocabularies have definitions.

Definition of colorDependent from IMS is "Information is conveyed that requires the ability to perceive colour." (It lists the term as "colour", but IMS has decided to adopt the schema.org suggestion of colorDependent since that is a much clearer name; updates to be published soon.)
https://www.imsglobal.org/accessibility/afav3p0pd/AfA3p0_DESinfoModel_v1p0pd.html#_Toc323719848

Definition of textOnImage from IMS is "Information is conveyed using text where the text is embedded in an image."
https://www.imsglobal.org/accessibility/afav3p0pd/AfA3p0_DESinfoModel_v1p0pd.html#_Toc323719895

Is this what everyone has in mind for ItemList syntax?

Example 1

{
  "@context": "http://schema.org/",
  "@type": "Movie",
  "accessMode": ["auditory", "visual"],
  "accessibilityFeature": ["audioDescription", "captions"],
  "accessModeSufficient": [ 
    {
      "@type": "ItemList", 
      "itemListElement": ["textual", "visual"], 
      "description": "Closed captioning"
    },
    {
      "@type": "ItemList", 
      "itemListElement": ["auditory"], 
      "description": "Audio description"
    }
  ],
  "accessibilitySummary": "Captions provided in English; short scenes in French have English subtitles instead."
}

Example 2

{
  "@context": "http://schema.org/",
  "@type": "Book",
  "name": "Alice in Wonderland",
  "accessMode": ["auditory", "textual", "visual"],
  "accessibilityFeature": ["alternativeText", "synchronizedAudioText"],
  "accessModeSufficient": [ 
    {
      "@type": "ItemList", 
      "itemListElement": ["textual"], 
      "description": "See the text"
    },
    {
      "@type": "ItemList", 
      "itemListElement": ["textual", "visual"], 
      "description": "See the text and images"
    },
    {
      "@type": "ItemList", 
      "itemListElement": ["auditory"], 
      "description": "Hear the text and image descriptions"
    },
    {
      "@type": "ItemList", 
      "itemListElement": ["auditory", "visual"], 
      "description": "Hear the text and see the images"
    },
    {
      "@type": "ItemList", 
      "itemListElement": ["auditory", "visual", "textual"], 
      "description": "Hear the text and see the text and images"
    }
  ],
  "accessibilitySummary": "Short descriptions are provided; long descriptions of the images are not needed for most readers."
}

Hi @danbri , we are about to go into IP review with the IDPF next week. It would really be helpful to have this hammered out and if possible some URI's we can point to when we submit our documents for review.
Thanks

Ok, I think we're pretty much there.

• First - @madeleinerothberg 's updated examples with ItemList look good to me.
• Second - I think there are some minor updates to pending.webschemas.org that need tweaking following the TPAC meeting.
• Third - @madeleinerothberg provided links/details for some of the coded values.

I'll work on getting the webschemas pending version in a form you can all say "looks good" to, tomorrow. After which I will move them directly out of "pending" into the candidate v3.2 release for final review and publication. Since we have had quite detailed discussions involved schema.org steering group members here there should be no big hurdles beyond that.

Looks good to me, let's ship :)

I'd be grateful if someone can write up an example as RDFa or microdata, not because I think it is a majority use case - although it seems like in catalogs it makes sense to serialise the data out in readable form - but to check that it matches my mental model…

Pinging as a reminder that the new examples need to be implemented in the pending pages for accessMode and accessModeSufficient.

Thanks for the nudge @madeleinerothberg

Done - see http://pending.webschemas.org/accessModeSufficient etc.

Odd, it works for me. Is http://pending.webschemas.org/accessModeSufficient
still 404 for you?

There are sometimes delays with the site due to multiple servers, caching
etc but it ought to be there for everyone by now. Copying @RichardWallis
who may have a theory if not.

On 18 October 2016 at 19:48, Charles LaPierre notifications@github.com
wrote:

hi @danbri https://github.com/danbri was the point of the link to see a
page not found in pending :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1100 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKZGZlZo-DdXoij8rKDtX3yerl_tvrGks5q1QZtgaJpZM4IF9Yn
.

At that address, I see boilerplate for 4 examples, but the first one is still the older syntax with no item list. (The other three all say "See also https://github.com/daisy/epub-revision-a11y/wiki/ePub-3.1-Accessibility--Proposal-To-Schema.org".)

Yes I believe it was a caching issue as it is working now. Thanks @danbri
So does this mean this has been accepted and will be in the next release of Schema.org?
We will need links we can link our spec to when this moves from pending to its final resting place.

@danbri I still don't see the new itemlist examples on the pending page -- either on webschemas.org or schema.org. Should those be visible now? See attached image.

You should see them on http://pending.webschemas.org/accessMode

These will get pushed to the stable-released-snapshots version of the schema.org site with our next release.

Hi @danbri Yes I do see this but the Example # 1 JSON-LD doesn't look right compared with Examples # 2, # 3, # 4 etc.. which do have itemListElement, but example # 1 looks different. I didn't realize that the JSON-LD tabs were specific to each example as they were all pointing to the same See also https://github.com/daisy/epub-revision-a11y/wiki/ePub-3.1-Accessibility--Proposal-To-Schema.org in the "Without-Markup" tab.

IE
Example # 1 JSON-DL tab has
<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>

whereas
Example # 2's JSON-LD tab has

{
"@context": "http://schema.org/",
"@type": "Movie",
"accessMode": ["auditory", "visual"],
"accessibilityFeature": ["audioDescription", "captions"],
"accessModeSufficient": [
{
"@type": "ItemList",
"itemListElement": ["textual", "visual"],
"description": "Closed captioning"
},
{
"@type": "ItemList",
"itemListElement": ["auditory"],
"description": "Audio description"
}
],
"accessibilitySummary": "Captions provided in English; short scenes in French have English subtitles instead."
}

Thank you, @clapierre! I only looked at #1, which is wrong. I see the right stuff now in #2 and #3. #4 seems to be a repeat of #3. The same is true for accessModeSufficent also.

Hello @danbri so we are getting close to the end of the IP review for the EPUB 3.1 Specification where we currently have the following:

Every conformant EPUB Publication must include the following [schema.org] accessibility metadata:
accessMode — the senses or faculties necessary to process or perceive the content (e.g., textual, visual, auditory, tactile).
accessibilityFeature — features and adaptations that increase the overall accessibility of the content (e.g., alternative text, extended descriptions, captions).
accessibilityHazard — any potential hazards that the content presents (e.g., flashing, motion simulation, sound).
accessibilitySummary — a human-readable summary of the overall accessibility, which includes a description of any known deficiencies (e.g., lack of extended descriptions, specific hazards).

How close are the new accessMode, accessModeSufficient and accessibilitySummary being adopted in Schema.org is there anything left to do?

This issue is being tagged as Stale due to inactivity.

This issue can be closed. The properties were integrated some time back.

Yes! we got there.

Can any of you summarise (or link) to any information on how these properties show up in the world of epub standards?

Including the metadata in the package document is a required/recommended part of conforming to the EPUB Accessibility specification.

There are also more specific examples of how the metadata is expressed in the techniques document.

They're also a recommended part of the upcoming W3C Audiobooks specification.

And we also detail them in the publishing knowledge base.