Ensure text equivalent for accessibility

[avneeshsingh]

One of the main principles of PWG charter is: "Recommendation-track deliverables will contain mechanisms to make Web Publications accessible to a broad range of readers with different needs and capabilities. This includes general Web Content Accessibility Guidelines (WCAG) and Web Accessibility Initiative (WAI) requirements of the W3C as well as requirements for international readers using different scripts and document formats.Profiles of Web Publications may be defined with more stringent accessibility requirements."

Further to it, the accessibility guidelines defined by WCAG 2.0/2.1 mandates accessibility for broader range of disabilities. http://www.w3.org/WAI/standards-guidelines/wcag/glance/

It is obvious that audio-only publications are accessible to low vision and visually impaired. But we also need to ensure that it is possible to produce audio publications which are accessible to people with other kind of disabilities for example people with hearing loss, slow learners etc. Therefore we do need to ensure that the specifications support text equivalent.

Some thoughts are:

• Can we leverage existing web specifications to add transcriptions and captions to audio track in the audio publications?
• Is the audio profile designed in a way to integrate well with text of the publication so as to provide audio sync with text?

These are basic design questions that we need to keep in mind as the audio profile is developed.

[llemeurfr]

Audio transcriptions and captions will, for sure, be required to be fully international and accessible themselves, therefore html resources. And you already state, Avneesh, that audio-text synchronization will be in the scope.

Isn’t it therefore a discussion to have in the context of the sync media profile? Such profile will be complex but powerful, and not all publishers nor user agents will be able to support it.

It’s IMO much better to have UAs explicitly supporting a sync-media profile than asking too much from UAs supporting an audio profile and at the end getting only partial support of this audio profile.

Laurent

Le 12 mars 2019 à 15:23, Avneesh Singh [email protected] a écrit :

One of the main principles of PWG charter is: "Recommendation-track deliverables will contain mechanisms to make Web Publications accessible to a broad range of readers with different needs and capabilities. This includes general Web Content Accessibility Guidelines (WCAG) and Web Accessibility Initiative (WAI) requirements of the W3C as well as requirements for international readers using different scripts and document formats.Profiles of Web Publications may be defined with more stringent accessibility requirements."

Further to it, the accessibility guidelines defined by WCAG 2.0/2.1 mandates accessibility for broader range of disabilities. http://www.w3.org/WAI/standards-guidelines/wcag/glance/

It is obvious that audio-only publications are accessible to low vision and visually impaired. But we also need to ensure that it is possible to produce audio publications which are accessible to people with other kind of disabilities for example people with hearing loss, slow learners etc. Therefore we do need to ensure that the specifications support text equivalent.

Some thoughts are:

Can we leverage existing web specifications to add transcriptions and captions to audio track in the audio publications? Is the audio profile designed in a way to integrate well with text of the publication so as to provide audio sync with text? These are basic design questions that we need to keep in mind as the audio profile is developed.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[wareid]

I think the best way to ensure we're in keeping with Sync Media is to ask @marisademeglio or @danielweck to review the draft once it is complete to ensure we're not blocking any of their work, but so far I think we're in line with what they are planning.

I believe there's tools out there for audio transcription but I'm not sure how many are built off a web specification.

[avneeshsingh]

Sync media can help in bridging the accessibility gap, but it is envisioned as a different profile for now. Which means that WP core is accessible, sync media profile is accessible but audio profile is not accessible.

This means that we need to ensure that sync media can be closely integrated with audio profile. Apart of this we can leverage the approach of supplementary content. We can have a table of content in audio profile that points to an audio track and below it we can have a link to text equivalent of audio track, preferably in HTML document. (this alternate representation does not need to be in the default reading order). I think that the existing specification allows this. This further elevates the significance of TOC in audio profile.

[marisademeglio]

What if we didn't make a sync media profile but rather used sync media as a property that could live on any reading order entry? So you could enhance any spine-level item (so to speak) with synchronized media. A very basic example would have an MP3 reading order and sync media files that provided a very coarse-level of synchronization (e.g. {text: file.html, audio: file.mp3}).

Not sure about putting this information on the TOC instead of reading order. My gut says no.

[iherman]

Not sure about putting this information on the TOC instead of reading order. My gut says no.

I am not sure this is a decision we have to make. If we go down the line, a solution would be to use the current LinkedResource entry such as:

{ 
    "type": "LinkedResource",
    "url" : "audiofile.mp3",
    "alternative" : "visual_equivalent.html"
}

This structure may appear in the reading order or the resources' list, it is up to the author. Note that our current rules require that the resources' list MUST include a reference to visual_equivalent.html, but that also means that further information about that resource (e.g., media type), can live there.

The only thing we must do for this is to introduce a term for alternative into the core manifest.

[marisademeglio]

Sure, this seems ok to me. Could alternative be media-type agnostic? I.e. it could point to a sync media file or a core media type?

So a reading system that supported a visual alternative presentation for an audio book would:

• query the media type of alternative (via one or many steps, depending on where that info lives)
• if it's html, it would display visual_equivalent.html for the duration of audiofile.mp3
• if it's sync-media, it would start playback according to the sync points

[HadrienGardeur]

FYI, this is exactly what we do in Readium:

• https://readium.org/webpub-manifest/extensions/audiobook.html#alternate-audio-resources
• https://readium.org/webpub-manifest/extensions/visual-narrative#3-alternate-visual-resources

We're also discussing it in the context of media overlays: https://github.com/readium/architecture/issues/88

[iherman]

@marisademeglio

Could alternative be media-type agnostic? I.e. it could point to a sync media file or a core media type?

Yes. Actually, I do believe that should be the case, we do not want a proliferation of such terms. I am not sure whether there is a relevant term in the schema.org vocabulary (I have not found one, but maybe somebody else is better at it); if not, we will have to define our own.

In the latter case we will have to find our own term, which is typically the kind of bikeshedding action best made around a table with an appropriate amount of drinks :-(

[avneeshsingh]

• +1 to have sync media as an overlay for aboth WP and AudioPub instead of living as a separate profile.
• The direction of this thread looks right. Author should get flexibility to provide alternate accessible HTML document or sync media for making AudioPub universally accessible.

[llemeurfr]

schema.org allows have multiple types, therefore having the option to create e.g. "type"=["Audiobook", "SyncMedia"] would be very effective: the provider could express the added accessibility features in an easy manner.

[BigBlueHat]

@llemeurfr there's actually several accessibility prefixed terms in Schema.org that would work better for expressing that support: https://schema.org/docs/search_results.html?q=accessibility In fact, many of them are informed by EPUB. 😃

[llemeurfr]

The solution of an array of alternate array of objects, also explored in https://github.com/w3c/wpub/issues/308, is getting consensus.

The type of these objects may well be a union of schema.org MediaObject, HTML objects (what is the schema.org corresponding object?) and SyncMedia objects (to be defined).

[wareid]

I'll be exploring the AudioObject in Schema to find out if it's the best implementation (strong looking like it is), but we will need to discuss some things with Schema.