V.6 was finalized on September 8, 2013. The major changes are simplifications: moving displayTransformability from a property to a property value of mediaFeature, adding a few more mediaFeature properties, reordering some items and making clear that two properties are only for use on softwareApplication and its subclasses. This simplicity does not detract from the information model, but eases adoption. The two samples were also updated to reflect these changes. V.6 was never fully publicized, but became a working model for the group.

Changes are being made for a .7 specification, which is expected to be published on November 8, 2013. There was a significant amount of work that went into this, but the net is minor changes and simplifications through the extensions mechanism and much better descriptions, There are a number of refinements to the properties, simplifying some with the use of extensions, adding new property values and renaming some of the properties to new names. While most of these are simple refinements in definition or name changes, some of the these name changes will impact all existing tagged documents. The most significant of these is to change mediaFeature to accessFeature and controlFlexibility to accessFlexibility. Details of these changes can be seen in the minutes of the working group in October and November 2013. We also changed the sense of values in accessHazard to allow both negative and positive assertions. This addresses issues 1, 2 and 3, as well as 8. This may be called V1.0 when done.The work was segmented into sections that were agreed upon by all and properties that needed more refinement and coordination with other efforts. The current proposal is segmented into a 1.0 proposal for four properties and a proposal for future effort, which will commence once 1.0 is adopted. Our current focus is on the adoption of 1.0.

There is now an Open Issues wiki page that will track issues as we drive to completion. Open items will be noted on this page, and the tracker will contain them all.

Vocabulary

The accepted vocabulary so far is at WebSchemas/Accessibility. This page is to track ongoing work, alongside the Issue tracker (see below)

The "extended" proposal (post 1.0)

There were a few properties that are still under consideration, but have been deferred for a later release (V1.1). accessMode needs more work to allow both the source and the augmented access mode. The is/has adaptation links work will be done in concert with the Bibex group, with details and timing left to be determined.
See also the Issues page (which will be edited down to the resolved issues for 1.0 and the open issues for future).

An access mode through which the intellectual content of a described resource or adaptation is communicated. The IMS model defines this as "The human sensory perceptual system or cognitive faculty through which a person may process or perceive information." If adaptations for the resource are known, the access modes of those adaptations are not included. The accessModes after visual in the list are all refinements of what is presented in the visual mode. Note that there is also a discussion of an augmentedAccessMode for future effort.

Identifier of a resource for which this is an adaptation for accessibility purposes. (to be handled with Bibex)

Use of extensions on bookFormat

The current use of bookFormat uses an enumeration for the type, but it only goes one level deep (EBook, Hardcover, Paperback)

This proposal also requests the expansion of bookFormat to include the following extensions of EBook and Paperback:

EBook/DAISY202

Ebook/DAISY3

Ebook/Mp3

Ebook/EPUB2

EBook/EPUB3

Ebook/BRF

EBook/PDF and other formats, mobi, etc.

Paperback/Braille

AccessFeature in more depth

The property accessFeature has multiple property values. Each of these is worth a short description.
First, there are three types of accessFeatures: transform, structure and augmentation.

Transform acccessFeatures are transformations of or enhancements to content that make it more accessible without changing the access mode. A large print book is a good example of this.

Structure accessFeatures describe the access aids that are provided to work within the media, such as the use of a table of contents, index or other items to be able to navigate to a point in content easily without linear scanning.

Augmentation accessFeatures make the content in one accessMode available in a different one. The augmentation type that most people are familiar with is alternativeText, which people have learned to apply to HTML images. While transform and structure accessFeatures do not require intelligence to apply, an augmentation normally will. As such, their quality cannot always be counted on.

There are three tables below, one for each of the types of accessFeatures. The extensions that can be used are unique to each of the types.

AccessFeature for transformation

Transform accessFeatures either state how content is available in a transformed state or is set up so that a user can transform it. These properties derive from WCAG 2.0 section 1.4 and surrounding areas. Common refinement/extensions of the property value are

/nnn (a specific pointsize, common for large print)

/CSSEnabled - that the resource has been designed to be mutable through CSS in an appropriate viewer

/yellowOnBlack or other specific common color combinations (for high contrast)

Expected Values

Transformed Access Mode

Description

highContrast

Visual, Textual

can add most comment colors as extensions, such as highContrast/yellowOnBlack, greenOnBlack, whiteOnBlack and blackOnWhite or just say /CSSEnabled if CSS is set up to allow these changes to be customized by the user.

largePrint

Visual, Textual

can add specific pointsize, as in largePrint/18 or just /CSSEnabled. Printed books (Visual) would never use the /CSSEnabled: that would be limited to electronic texts. A physical book would, if any extension, use a pointsize.

resizeText

Textual

either /CSSEnabled or the extension /taggedPDF if the PDF allows resize and reflow.

displayTransformability

Textual

The document is set up for CSS display transformability.

enhancedAudio

Auditory

For prerecorded audio content that contains primarily speech in the foreground.

/noBackground

/reducedBackground

/switchableBackground

AccessFeature for structure

There is only one property value for structuralNavigation, which is listed below.

Expected Values

Description

structuralNavigation

table of contents or similar resource to allow higher-level document navigation, which can be extended as /tableofContents, /index, /headings, /tags, /bookmarks, /printedPageNumber if one wants to give more detail

AccessFeature for augmentation

Augmentation is the most interesting of the accessFeatures. It explains how an intelligent actor (generally a person, but could be computer-based) will take the intellectual content of one access mode and make it available in a different access mode. One can debate whether the source or the destination access mode is of more importance; I have chosen to organize this by the destination access mode that the source access mode was augmented to.
Note that there is a common extension that is used to represent the refinement of the visual content types (see all of the /*OnVisual in access modes). so that one can express accessFeatures for specific parts of the visual content.

The use of one of these specific ASCII/XML encodings for mathematics or chemistry. These can have extensions specified, but are rarely needed.

transcript

Textual

Auditory

The addition of a separate transcript to convey the meaning of the audio.

captions

Visual

Auditory

The addition of synchronized text (closed captions) to convey the meaning of the audio. Note that while many captions may be implemented as textual in the transport, users think of them as being a visual appearance.

signLanguage

Visual

Auditory

The presentation of audio in sign language in the visual presentation. The most likely extension is /sgn-en-us or other ISO 639 sign language code.

audioDescription

Auditory

Visual

Audio descriptions are available (e.g., via the HTML5 track element). Common extensions are for the various "onImage" refinements noted above.

braille

Tactile

Visual or Textual

braille content or alternative is available (e.g., eBraille or print braille) This can have extensions for the different types of braille, /ASCII, /music, /math, /chem or /nemeth) (also consider /contracted and /gradeII or other nomenclature... pretty open)

tactileGraphic

Tactile

Visual

tactile graphics have been provided, as described in the BANA Guidelines and Standards for Tactile Graphics.

tactileObject

Tactile

Visual

tactile 3D objects have been defined and a 3D object or instructions to build one are available.

Example Markup

Example 1 (Book)

The following example shows how the accessibility metadata will be used to enhance Bookshare records. Note that our markuup has advanced since this early illustrative example. A description and the process and a corpus of searchable books can be found at the accessibility metadata website.

More examples are referenced in the Discussion and Related Work section. Note that there has been discussion of the accessMode (which would have a value of textual and visual" and isAdaptation, which would be urn:isbn:9780030426599, but these are still in flux and have been removed from the example)

<dd>This book is currently only available to public K-12 schools and organizations in the United States for use with students with an IEP, because it was created from files supplied by the NIMAC under these restrictions. Learn more in the NIMAC Support Center.</dd>

Example 2 (Video)

This example shows how the accessibility metadata can be used to augment a record for a video. Note that the access modes appear in the content for this page, but do not have accesssibility metadata tags added, as this is not in the 1.0 specification. Neither is hasAdapation, which would have a URL like to <a itemprop="hasAdaptation" href="http://www.teachersdomain.org/asset/echo07_vid_climate_dvs/">