Next Accessibility Metadata Meeting Agenda

Skip to end of metadata
Go to start of metadata

December 4, 2013 Accessibility Metadata working group call

Weekly Meeting
Schedule: There is no call scheduled yet for the future.  The next call will be Wednesday, December 4, 9:00AM PST (California), 12:00PM EST (Ontario, New York), 5:00PM in London and Madrid and 6:00 PM on the continent, 4:00 AM in Australia. For general time zone availability, I am including a link to an authoritative time zone source.
Conference call: +1-866-906-9888 (US toll free), +1-857-288-2555 (international), Participant Code: 1850396#
Etherpad: The link for the piratepad for today is (12/4/2013)
IRC: #a11ymetadata (although more of the collab seems to happen in the etherpad)

The goal of the call will be a review our progress with the properties that are now available on (or will be shortly), future process and the properties that did not make into 1.0. We'll also discuss our process as we go forward.

The public site is and our twitter hashtag is #a11ymetadata.

Review of progress on and remaining issues

  1. Review of events as the current properties moved into (V1.0) over the past month
    1. We recommended to move forward with accessibilityFeature, accessibilityHazard, accessibilityAPI and accessibilityControl.
    2. We decided to eliminate the distinction between app and content and all the proposed properties will be part of CreativeWork.
    3. We are not going to include ATCompatible.
    4. We are going to wait for the soon to be published BibEx workExample and exampleOfWork properties instead of using hasAdaption and isAdaptationOf.
    5. We are going to hold on accessMode. We will explore using the encodingFormats property. For example a book may have encodingFormats of text/html and image instead of accessModes of textual and visual. I just realized we need to think through of other HTML visual/non-textual elements, such as canvas.
  2. Finalizing any wiki cleanup
    1. Matt and Madeleine still have some concerns regarding the noX terms on accessibilityHazard, so we should discuss how to resolve (proposal is top add Hazard to the end of the terms)
    2. Matt's discussion on the utility of the various transform properties and extensions (clarifications that came up as he did more writing on this)
    3. Cleaning up the issue list and removal/archive of items before 1.0
  3. Establishing a process for maintaining, discussion and governance of the terms on the wiki
    1. We will use the vocabs mailing list for maintaining terms and publish stable versions as Interest Group Notes in the Semantic Web Interest group (you may need to click on a highlevel menu first) and the home page of the SWIG.
    2. We will use the WebSchemas/Accessibility wiki for maintaining terms
    3. We need to clean up the crosswalk between ONIX and In this process, we identified that we may need a accessFeature term of mediaOverlays for ONIX accessibility item 20 and that ONIX accessibility items 11 and 13 combined would map to structuralNavigation. We will reach out to with Graham Bell for his input. Note that some of this has been done, but needs another set of eyes
  4. Any other issues on the wiki and getting traction around the specification.

Next items on the overall agenda (the properties for 1.1 and beyond)

  • accessMode, augmented access mode and the various proposals for the available access modes - starting the process with use cases
  • is/hasAdaptation, the referral of this to the bibex group and how to best handle the various relationships. We should give them guidance on this

Agreement on the basic use cases for 1.1 around accessMode and augmentedAccessMode

As we move forward on accessMode and its properties, it's useful to have all of the use cases identified so that we 
There are six use cases below

  • a person looking for a specific media type (video) with a accessibiliyFeature (caption) - media type+accessibilityFeature does the job well
  • a person driving in a car who can only work with audio content or content that can be expressed in audio - needs augmentedAccessMode to easily determine useful content, but may still have a bias to content that fits by accessMode ahead of augmentedAccessMode
  • a teacher who is leading a class, where some of the students have disabilities. They would like to find resources for the class, finding, if possible, the best resources that can be used by the most students - another case for augmentedAccessMode for search hits, but then seeing the accessMode and accessibilityFeatures so that they can make the best decision
  • When a book is made available, it may be available with different accessModes and accessibilityFeatures (the current bookshare is a very good example... a book can be available in braille (brf), Daisy with images, Daisy w/o images and Daisy Audio, all as adaptations of the source book). In this case, the various accessibilityFeatures may be delivered in specific packages, rather than being available on the source file.
  • When a book is available on O'Reilly or Amazon, it may be available in a few formats from the offering page (paper, epub, mobi, pdf), hardbound, paperback, audioCD or AudioService (Audible). Sometimes these are available for access directly from the page (O'Reilly). Other cases (Amazon), has links over to that page.
  • accessModes for epub3 files, which can contain multiple renditions. For example (see draft epub3 content below), a single epub file can have multiple renditions... a graphic novel, a text novel and a dramatic audiobook reading. These need to be made available to the user by accessMode.

Also, note that we may consider that some media types have a default accessModes. For example, a video would default to having auditory and visual. An audio file, such as an MP3 would default to just auditory. There are a small set of these that would be known, for the most common defaults. 

3.4.4 The rendition:accessMode attribute

The rendition:accessMode attribute identifies the way in which intellectual content is communicated in a Rendition, and is based on the "Access Mode" property defined in [ISO24751-3].

Attribute Name


may be specified on Container Document rootfile elements.

must be one or more of the values: auditory, textual or visual

This property defines the primary access mode(s) for a given Rendition. For example, although a textual work may include images, audio and video, its primary means of conveying information is the text. Likewise, a visual work might include alt text and/or descriptions, but these adaptations are not listed as a textual mode for the Rendition for the purpose of selection.

The way in which information is encoded also needs to be considered when designating an access mode. If a work has text components, or is completely textual in nature, but that content is burned into an image format, the access mode is visual (e.g., character dialogue in a JPEG page of a comic or a scan of a document).

A rendition may include more than one primary access mode. For example, the textual version may also embed the auditory version using media overlays. In such cases, the attribute should list each primary access mode available.

If a User preference is defined, the attribute evaluates to true if that preference matches any of the access modes defined in it, otherwise it evaluates to false. If no User preference is defined, the Reading System should ignore the attribute when selecting from the available Renditions.

The following example shows an EPUB Publication with an image-based Rendition and a text-based serialization available.

<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container"
<rootfile full-path="EPUB/comic/package.opf"
<rootfile full-path="EPUB/novel/package.opf"

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.