-
Notifications
You must be signed in to change notification settings - Fork 8
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
a11y and audio #28
Comments
I fully agree with this, as I've voiced the same concern that it's not clear how to apply the audio hazard when we don't have specific guidelines to check against like we do for flashing hazards. I don't know if we can solve the issue in an EPUB revision, though, as this should be guidance developed for the property value itself and should cover all cases. But in the absence of clear guidance, I don't know what we recommend to people. Maybe we should note the problem of a lack of clarity in the techniques and suggest not using the "none" value if there is any auditory content in the publication? |
The issue was discussed in a meeting on 2021-03-25
View the transcript3. Audio hazardsSee github issue #1302. Avneesh Singh: in the hazards there are parameters for visual hazards in WCAG (e.g. flashing no more than 3 per second) Matt Garrish: i looked into this years back with Madeleine Rothberg George Kerscher: sudden increases in volume were the problem, could potentially damage hearing Bill Kasdorf: "any audio" seems broad Charles LaPierre: increase in decibel level is probably a good way to put it
Charles LaPierre: probably some text around those is all we need Ben Schroeter: I think its kind of meaningless unless its quantifiable
Ben Schroeter: anything else (e.g. warning there could be explosions) is not likely to be enforceable Charles LaPierre: i think some of that could be machine checked (e.g. with AI) Avneesh Singh: we can rely on research done by wcag on this
Wendy Reid: we should probably ask for quantifiable information that we can provide to content producers Avneesh Singh: we need proven research to drive the parameters Matt Garrish: wcag may not have an easy answer on this for us Bill Kasdorf: I bet there's an authoritative place to define issues like this (e.g. audiology) Avneesh Singh: for now we cannot provide the necessary parameters George Kerscher: i think that is the right approach, but i would expect that audiobook publishers and publishers in general would look to us first and not go digging around in wcag Avneesh Singh: is something like that already in the spec? Matt Garrish: there are very general descriptions of hazardous audio, but we don't have references to anything specific where people can go to get more info Avneesh Singh: George_ you can go through what we have currently in the spec
Avneesh Singh: next call about EUAA |
To pick up on a point I was trying to make yesterday, should we consider retiring "sound" in the interest of finding more specific terms? Unlike flashing and motion simulation, sound is non-specific about what it refers to. We could instead, for example, add something like "loudness" to address the concern raised here. If we can quantify how to test for auditory seizure risks we could then add separate terms for it, like buzzing or ringing. This would be clearer and make more sense than a catch-all like "sound". |
I agree with this approach; it provides more guidance to content creators.
|
It looks that this will lead us to some kind of basic research. Since this work is related to techniques which can be updated more frequently and to schema.org values, is it better to delegate this work to Publishing CG accessibility task force, and ease the pressure of tight timeline of EPUB accessibility under EPUB 3 WG? |
The issue was discussed in a meeting on 2021-05-13
View the transcript4. Path forward for sound hazardSee github issue #1302.
Matt Garrish: the sound hazard isn't actually tied to a specific testable outcome Tzviya Siegman: before we add this we should refer this to AG group Avneesh Singh: i have emailed them George Kerscher: we can bring it up, yes, but in a way that makes it clear that we don't want to drive it
Matt Garrish: i'm not an expert, but from what i've read it seems like the hazard is very subjective to the individual Charles LaPierre: maybe having the umbrella category of sound is the best we can do for now Avneesh Singh: don't think that this issue is specific to epub, the vocab is from Schema, and the expertise necessary to develop it has to come from a11y experts in this field
Avneesh Singh: action item for George and tzviya to raise it with WAI and AG |
Just a note that the AG group raised this issue in their call on May 18 (in relation to the email that @avneeshsingh sent to that group) as a topic to discuss with us at TPAC in October. |
Should we transfer this issue to the vocabulary CG to figure out, as it's not specifically an EPUB problem? I'm just not sure what we should say for now in the techniques about sound hazards. My half-formed thoughts are that:
Since there isn't clear guidance on how to use sound yet, we don't recommend setting that one either positively or negatively at this time when a publication contains auditory content. It's not ideal, but is effectively like saying any sound hazards are unknown (creating an unknownSoundHazard value probably doesn't help anything, as it's the whole issue that is ambiguous). If the publication does not contain any auditory content, then setting "noSoundHazard" is okay, of course. |
Yes, we should move this to the Vocab CG. |
The issue was discussed in a meeting on 2021-11-11 List of resolutions:
View the transcript3. a11y and audio: #1302.Matt Garrish: almost a given that this will happen at this point. See github issue epub-specs#1302. Avneesh Singh: issue is about audio hazards, which are underspecified currently. See github pull request epub-specs#1903. Avneesh Singh: what should be considered an audio hazard?. Matt Garrish: we're referencing here the Schema metadata (which was formerly IMS metadata), so not much we can do. Avneesh Singh: if we want to put pressure on WAI, would it make more sense to keep this issue in epub 33 wg. Matt Garrish: we should maybe open an issue in WAI tracker.
Matt Garrish: you sent an email to them earlier this year to put it on their radar, but it may have been forgotten now.
John Foliot: i would recommend that we not take this to a11y guidelines wg, it'll get lost. Matt Garrish: great! Thank you.. John Foliot: two categories of sound hazards I can think of: 1) auto-start/loud, and 2) specific types of sounds like explosions. Avneesh Singh: APA is also more research oriented. John Foliot: AG is focused on a11y scoring issue right now. You can log the issue against WCAG3 if you want, but I would not recommend. George Kerscher: maybe this is something that can go into DaisyKB, that people are aware of volumes, that if there are sudden amplitude jumps that a hazard should be entered into epub metadata. Matt Garrish: yeah, we can certainly do that. Within our domain.. Avneesh Singh: we will discuss that further via email. |
At the moment I can't reach the actual web page that has it (browser can't find idpf.org) but archive.org had it - in 'META-004: Identify accessibility hazards' with respect to audio it mentions:
There does not seem to be an expansion on that, for how to evaluate an audio as to whether or not it may have one of the patters that can be a trigger. I tried searching the web for an evaluation method but did not find one.
Can the doc be updated to give a reference for evaluation?
-=-
Also somewhat related, maybe belongs with WAI for inclusion in their WCAG general techniques and not here - many people (myself included) have an autistic input overload trigger caused by either loud audio or sudden changes in audio volume. I couldn't watch Big Bang Theory because they mixed the laugh track to be really loud compared to the rest of the show, for example, causing an input overload that stressed me.
Using loudness normalization as specified in EBU R128 should be an accessibility technique for audio and video - either by providing the metadata tags or (what I do with audio) applying EBU R128 to the source before lossy encoding, so that it is loudness normalized even if the player doesn't support the metadata tags.
EBU R128 isn't the only scheme but it is the best (ReplayGain for example I believe only takes RMS into consideration which is often inaccurate method) and EBU R128 seems to be gaining a lot of support in the broadcasting industry, including streaming services, so if a user has their volume set what they like when listening to spotify and they then open an ePub with an audio or video that uses EBU R128 the perceived loudness will be where they want it.
The text was updated successfully, but these errors were encountered: