-
Notifications
You must be signed in to change notification settings - Fork 9
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
Comments
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 ***@***.***> 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.
|
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. |
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. |
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. 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 {
"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 The only thing we must do for this is to introduce a term for |
Sure, this seems ok to me. Could So a reading system that supported a visual alternative presentation for an audio book would:
|
FYI, this is exactly what we do in Readium:
We're also discussing it in the context of media overlays: readium/architecture#88 |
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 :-( |
|
schema.org allows have multiple |
@llemeurfr there's actually several |
The solution of an array of 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). |
I'll be exploring the |
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:
These are basic design questions that we need to keep in mind as the audio profile is developed.
The text was updated successfully, but these errors were encountered: