Accessibility, schema.org Microdata and Publications

• Tweet
• Email
• Sumo

• Tweet
• Email

This is a guest post from Julian Calderazi. Julian is an ebook developer from digitalbe.com in Buenos Aires, Argentina.

We normally read that ‘producing good books is producing accessible books’, which is true. But one of the key ways to make your accessible content discoverable is to use accessibility metadata in all of your ebooks. Here we will go into Why you should start considering accessibility on your production workflow, How you can make your content more accessible and When is the right time to start doing it.

The Basics

The short-form for ACCESSIBILITY is a11y. In between the first and the last letter (a-ccessibilit-y) are 11 characters, that is how we reach a11y.

When producing content, keep in mind that we don’t know who will consume it. Publishers and ebook producers are responsible for producing content that must be readable by the widest range of consumers possible. In the end, this will lead to more readers and drive more sales.

Usually, when people read Accessibility they think about blind people, and while that is partially true, print disabilities are a broader, more diverse category.

Visual

This sub-category includes, of course, non-sighted readers, but also readers with low vision or even the average ageing person. More examples include Myopia or color blindness, Glaucoma or Albinism.

Auditory

While ebooks are a visual interface, the usage of captions for sound media must be considered for hearing-impaired consumers. Some examples of auditory challenges are Presbycusis, Acoustic traumas or Auditory processing disorder.

Motor

There’s a wide range of assistive technology to support this category, from keyboards to eye trackers or single buttons to navigate content. People with RSI, Cerebral Palsy, Parkinson’s or Muscular Dystrophy fall into this grouping.

Cognitive

This classification includes people with Dyslexia, Global developmental delay or Down’s Syndrome. Fonts can make a big difference to readers from this category. (OpenDyslexic is a free open source typeface designed to increase readability for Dyslexic people and has been included in Kindle since 2016.)

Apart from the human conditions stated above, we can also find ourselves with temporal disabilities, like a hand or eye injury or a even the more mundane example of driving and not being able to use the phone so we use the hands-free option.

Schema.org

A big player in this conversation is schema.org microdata & publications. Schema.org is a collaborative community that creates, maintains and promotes vocabulary schemas for structured data. This means that applying schema microdata to content so that we define exactly what it is and how it should be treated.

Metadata for accessibility plays a fundamental role in producing accessible content.

Why

An online bookstore that aggregates or distributes content from publishers (or authors) doesn’t know the production quality of the publications submitted. We already know how important metadata is in our content-saturated marketplace, but accessibility metadata takes that to the next level.

By using accessibility metadata you will be providing the consumer specific information about the usability of your publication. By allowing the consumer to review the quality of your content, you will be giving him or her the chance to decide whether it is appropriate for their needs. This a11y microdata means that potential consumers looking for certain information can be certain whether or not they can consume it.

Even your content is not fully accessible, you can still use accessibility metadata. This way you will avoid frustrations for those whose needs you cannot cover.

It is important to note that Accessibility Recommended Specification 1.0 were born and developed to be used in the package document (.opf) of any EPUB – version 2 or 3. If you still have old EPUB 2 content being distributed, or if you are developing on the latest version of accessible metadata, microdata can be implemented at a very low cost to improve discoverability of your ebooks for your consumers.

How

For ease of use, we have divided these properties into MUST, RECOMMENDED and OPTIONAL.

MUST

accessMode property

Defined as a human sensory perceptual system or cognitive faculty necessary to process or perceive the content. In short, the primary access modes options are:

• textual — contains text content (headings, paragraphs, etc.).
• visual — contains visual content such as images, graphics, diagrams, animations and video.
• auditory — contains auditory content such as standalone audio clips and audio soundtracks for video content.
• tactile — contains tactile content such as embedded braille and tactile diagrams.

accessibilityFeature property

It is the way for identifying all features and adaptations included in your Publication at a fine-level. The example used in this case is the inclusion of MathML and alternative text on images (see examples below).

accessibilityHazard property

The three widely-recognized hazards are:

• Flashing – in which if it flashed more than three times a second it can cause seizures (videos or animations).
• Motion stimulation – which refers to resources that by simulating motion can cause consumers to become nauseated.
• Sound – certain sound patterns such as ringing and buzzing can cause seizures.

accessibilitySummary property

An accessibility summary (text) will provide a brief description of the accessibility (or lack of) characteristics of your Publication.

RECOMMENDED

accessModeSufficient property

Although it already is a recommendation, I highly recommend the use of it. access mode property (explained above) identifies the default nature of the media used in the publication. Sufficient access modes will identify which modes, or sets of modes, a consumer requires to read the publication.

Sufficient access modes take into account the affordances and adaptations that have been provided (when developing the Publication), allowing a consumer to determine whether the content will be usable regardless of its default nature.

The access modes should be repeated for each set of sufficient access modes. (See example for both EPUB3 & EPUB2 below)

Because the accessMode metadata isn’t clear whether a textual access mode is sufficient to read the entire publication, or whether a visual one is, it only informs that there are two modes required by default. This discrepancy is why sufficiency is also important to know (although as I wrote before, it is recommended but not mandatory).

The first set of sufficiency metadata the Producer states will establish the textual and visual requirement. The order in which the access modes are listed is not important. The only requirement is that they are comma separated. For example, if the Producer has included descriptions for all the images, it can also indicate that a purely textual access mode is sufficient to read the content:

<meta property="schema:accessModeSufficient">textual</meta>

Without this metadata, consumers would not know that they could read the publication also via its text content.

Note that sufficiency of access is often a subjective determination of the producer based on their understanding of what information is essential to comprehending the text. Some information loss occurs when, for example, the consumer is not able to see a video, but the producer might regard the visual or auditory losses as inconsequential if a transcript provides all the necessary information to understand the concepts being conveyed.

OPTIONAL

accessibilityAPI property

Assistive technologies can interact with EPUB Publications. ARIA (Accessible Rich Media Applications) compatibility is identified in the schema.org accesibilityAPI property. Refer to it for more information about it and its values.

accessibilityControl property

Not every consumer will use the same input control methods. Not only the device will affect the input method (tactile/mouse or mobile/desktop), but also will the consumer’s physical abilities. So consumers might use any number of input methods. This means all users need to know what input controls will work with the content as it will affect not only whether they can operate the content but also on what devices.

As happens with the accesibilityAPI property, the input control methods that can be used to read a Publication are highly influenced by the accessibility of the App or device being used. So the responsibility of the Producer appears when dynamic content is included and it is needed to ensure that it is accessible to different input control methods.

You can find input control methods in the schema.org accesibilityControl property. You will need to repeat this property for each input control method.

Examples

EPUB3 schema.org metadata sample

<package … >
<metadata>
…
<meta property="schema:accessMode">textual</meta>
<meta property="schema:accessMode">visual</meta>
<meta property="schema:accessModeSufficient">textual,visual</meta>
<meta property="schema:accessModeSufficient">textual</meta>
<meta property="schema:accessibilityFeature">transcript</meta>
<meta property="schema:accessibilityFeature">MathML</meta>
<meta property="schema:accessibilityFeature">alternativeText</meta>
<meta property="schema:accessibilityHazard">flashing</meta>
<meta property="schema:accessibilityHazard">noMotionSimulationHazard</meta>
<meta property="schema:accessibilityHazard">noSoundHazard</meta>
<meta property="schema:accessibilitySummary">
     The video in chapter 2 presents a flashing hazard. A transcript is provided that 
     covers all the essential information contained in the video. The publication otherwise 
     meets WCAG 2.0 Level A.
</meta>
</metadata>
…
</package>

EPUB2 schema.org metadata sample

<package … >
<metadata>
…
<meta name="schema:accessMode" content="textual"/>
<meta name="schema:accessMode" content="visual"/>
<meta name="schema:accessModeSufficient" content="textual,visual"/>
<meta name="schema:accessModeSufficient" content="textual"/>
<meta name="schema:accessibilityFeature" content="transcript"/>
<meta name="schema:accessibilityFeature" content="MathML"/>
<meta name="schema:accessibilityFeature" content="alternativeText"/>
<meta name="schema:accessibilityHazard" content="flashing"/>
<meta name="schema:accessibilityHazard" content="noMotionSimulationHazard"/>
<meta name="schema:accessibilityHazard" content="noSoundHazard"/>
<meta name="schema:accessibilitySummary" content="The video in chapter 2 presents a flashing hazard. 
     A transcript is provided that covers all the essential information contained in the video. The 
     publication otherwise meets WCAG 2.0 Level AA."/>
</metadata>
…
</package>

When

Using this metadata is a relatively easy way of creating a better reading experience for consumers while making content more accessible. There is no reason why we shouldn’t be doing it already. It is simple, it is easy. You may find your content doesn’t need some of the properties described but it is always good to know they exist. And building use of these descriptors into your workflow will quickly become part of your #eprdctn muscle memory.