a11y and audio

[VeryGoodErotica]

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:

sound — certain sound patterns, such as ringing and buzzing, can cause seizures.

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.

[mattgarrish]

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?

[iherman]

The issue was discussed in a meeting on 2021-03-25

• no resolutions were taken

View the transcript

### 3. Audio hazards _See github issue [#1302](https://github.com/w3c/epub-specs/issues/1302)._ **Avneesh Singh:** in the hazards there are parameters for visual hazards in WCAG (e.g. flashing no more than 3 per second) … but no equivalent for audio hazards … how are publishers to classify which audio will causes issues for users? **Matt Garrish:** i looked into this years back with Madeleine Rothberg … in the github tracker, one potential standard was indicated … but it is harder to classify these sorts of audio hazards than with visual hazards … maybe we just play it safe and recommend that if there is any sound at all then there might be a hazard … if the absence of a clear standard, what do we say? **George Kerscher:** sudden increases in volume were the problem, could potentially damage hearing … that's the sort of thing that should be flagged as an audio hazard … that sudden increase in sound that could damage hearing **Bill Kasdorf:** "any audio" seems broad … it would catch even the books with only narration **Charles LaPierre:** increase in decibel level is probably a good way to put it … and then also something about tones (like in those hearing tests) > *Matt Garrish:* q **Charles LaPierre:** probably some text around those is all we need **Ben Schroeter:** I think its kind of meaningless unless its quantifiable > *Matt Garrish:* +1 to ben **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 > *Gregorio Pellegrino:* +1 to Avneesh, I would forward it to WCAG **Wendy Reid:** we should probably ask for quantifiable information that we can provide to content producers … there is a body of research on the topic of hazardous sounds … and with the increasing popularity of audiobooks, i've seen increases in the creative use of sound **Avneesh Singh:** we need proven research to drive the parameters **Matt Garrish:** wcag may not have an easy answer on this for us … and what does it mean to users? If we say that it has a sound hazard, there are a variety of ways that users could be affected (i.e. seizures? damage hearing?) … what does it mean to users? … more work to be done in this area **Bill Kasdorf:** I bet there's an authoritative place to define issues like this (e.g. audiology) … we should rely on those sources rather than try to strike out on our own **Avneesh Singh:** for now we cannot provide the necessary parameters … if wcag comes back with answer, then great … but with the knowledge we have now, we should maintain the status quo … my preference would be if the WAI work on this on the level of the broader W3C, instead of making this an epub a11y thing **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 … if we put informative information, even though we can't point to the research, i think that would benefit people **Avneesh Singh:** is something like that already in the spec? … examples, patterns etc? **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 … e.g. there was reference in the issue to a standard to define what "loud" meant **Avneesh Singh:** George_ you can go through what we have currently in the spec … the agenda also lists a number of issues that mgarrish has closed since last meeting … we can comment on those right now, or you can put your comments in the issue tracker > *Charles LaPierre:* [https://audiology-web.s3.amazonaws.com/migrated/niohlprevention.pdf_53996fb4c1ca13.61907521.pdf](https://audiology-web.s3.amazonaws.com/migrated/niohlprevention.pdf_53996fb4c1ca13.61907521.pdf) > *Matthew Chan:* Bill_Kasdorf provides example of CDC standard of sound that may impact hearing > *Bill Kasdorf:* [https://www.cdc.gov/nceh/hearing_loss/what_noises_cause_hearing_loss.html#:~:text=Sound%20is%20measured%20in%20decibels,immediate%20harm%20to%20your%20ears.](https://www.cdc.gov/nceh/hearing_loss/what_noises_cause_hearing_loss.html#:~:text=Sound%20is%20measured%20in%20decibels,immediate%20harm%20to%20your%20ears.) **Avneesh Singh:** next call about EUAA … i've send an updated calendar invite around accounting for DST ---

[mattgarrish]

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".

[GeorgeKerscher]

I agree with this approach; it provides more guidance to content creators.

[avneeshsingh]

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?

[iherman]

The issue was discussed in a meeting on 2021-05-13

• no resolutions were taken

View the transcript

### 4. Path forward for sound hazard _See github issue [#1302](https://github.com/w3c/epub-specs/issues/1302)._ > *Avneesh Singh:* some pointers to some parameters for reference: > *Avneesh Singh:* See [CDC document](https://www.cdc.gov/nceh/hearing_loss/what_noises_cause_hearing_loss.html#:~:text=Sound%20is%20measured%20in%20decibels,immediate%20harm%20to%20your%20ears.) > *Avneesh Singh:* See [Audiology document](https://audiology-web.s3.amazonaws.com/migrated/niohlprevention.pdf_53996fb4c1ca13.61907521.pdf) **Matt Garrish:** the sound hazard isn't actually tied to a specific testable outcome … there are sound patterns that cause seizures, but not sure if there is any standard for testing for that … changes in loudness can also cause issues … right now we have a property called sound that isn't specific to anything … what i put in the tracker after is whether we should move away from "sound" towards descriptors of the hazards that can be caused by sound … e.g. loudness … e.g. buzzing … might be more testable … my concern is that this would be coming from epub a11y spec WG, when maybe we should just be referring out to some other standard … not sure if we should try to rush something into this revision timeline … or if we should be looking into this more deeply, consulting other experts, etc. **Tzviya Siegman:** before we add this we should refer this to AG group **Avneesh Singh:** i have emailed them … but it would help if you and George can elevate it with 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 … i'd be happy to close this issue for now > *Charles LaPierre:* +1 to waiting **Matt Garrish:** i'm not an expert, but from what i've read it seems like the hazard is very subjective to the individual … that's why i'm not sure how easy it is to test for something like this … makes it especially difficult **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 > *Matt Garrish:* +1 **Avneesh Singh:** action item for George and tzviya to raise it with WAI and AG

[mattgarrish]

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.

[mattgarrish]

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:

• we should advise against using the value "none" since it's a point-in-time statement (i.e., new hazards could always be identified in the future, making such a statement unreliable)
• only recognize flashing and motion simulation as hazards to address either in the positive or negative for all publications

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.

[GeorgeKerscher]

Yes, we should move this to the Vocab CG.

[iherman]

The issue was discussed in a meeting on 2021-11-11

List of resolutions:

• Resolution No. 1: Approve PR 1903.

View the transcript

### 3. a11y and audio: #1302. **Matt Garrish:** almost a given that this will happen at this point. _See github issue [epub-specs#1302](https://github.com/w3c/a11y-discov-vocab/issues/28)._ **Avneesh Singh:** issue is about audio hazards, which are underspecified currently. _See github pull request [epub-specs#1903](https://github.com/w3c/epub-specs/pull/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. … lack of standard on when audio constitutes a hazard. … next step will be to pursue this in the new vocabulary CG. **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. > *Tzviya Siegman:* +1 to mgarrish. **Matt Garrish:** you sent an email to them earlier this year to put it on their radar, but it may have been forgotten now. > **Proposed resolution: Approve PR 1903.** *(Avneesh Singh)* > *Matt Garrish:* +1. > *Wendy Reid:* +1. > *Matthew Chan:* +1. > *Gregorio Pellegrino:* +1. > *Wendy Reid:* george: +1. > *Murata Makoto:* +1. > ***Resolution #1: Approve PR 1903.*** **John Foliot:** i would recommend that we not take this to a11y guidelines wg, it'll get lost. … they are very busy now. … maybe take this to APA, research questions TF. **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. … this sort of thing is perfect for the research questions TF. **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. … for now mgarrish please open the issue with APA. … and we may point AG to this issue again in future. … and also email WAI group to raise this question.