Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure text equivalent for accessibility #44

Open
avneeshsingh opened this issue Mar 12, 2019 · 13 comments
Open

Ensure text equivalent for accessibility #44

avneeshsingh opened this issue Mar 12, 2019 · 13 comments

Comments

@avneeshsingh
Copy link

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
Copy link
Contributor

llemeurfr commented Mar 12, 2019 via email

@wareid
Copy link

wareid commented Mar 12, 2019

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
Copy link
Author

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
Copy link

marisademeglio commented Mar 20, 2019

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
Copy link
Member

iherman commented Mar 21, 2019

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
Copy link

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
Copy link

HadrienGardeur commented Mar 21, 2019

@iherman
Copy link
Member

iherman commented Mar 22, 2019

@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
Copy link
Author

  • +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
Copy link
Contributor

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
Copy link
Member

@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
Copy link
Contributor

The solution of an array of alternate array of objects, also explored in w3c/wpub#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
Copy link

wareid commented May 7, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants