From:  Chris Mills <cmills@mozilla.com>
Date:  11 Nov 2015 19:33:50 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.accessibility
Subject:  

Re: Muting web audio when a screenreader is saying something

NNTP-Posting-Host:  63.245.214.181

Thanks for the comments, Sylvia. A couple of follow-ups below.

> On 10 Nov 2015, at 21:47, Silvia Pfeiffer  wrote:
> 
> On Wed, Nov 11, 2015 at 12:52 AM, Chris Mills  wrote:
>> I was having an interesting conversation with Henny Swan from The Paciello Group last week - she was saying that a very common complaint from screenreader users that she hears is web-based audio drowning out screenreader output when users navigate to a web page that features audio or video tags, etc. Especially ones set to autoplay.
>> 
>> I was wondering if it would be possible to write an addon that mutes (or at least reduces the volume of) audio coming from a webpage when a screenreader is saying something. Is there any kind of custom event we can use for this?
> 
> 
> For audio and video elements, there is an extensive API that can be
> used, including reading and setting volume. That could be exposed
> through an extension to a specific key-combination (if there is any
> key-combintation still available that the screenreader isn't using)
> and thus the user could control the volume manually.

I’m pretty familiar with the HTML media API, so I could probably code this up, if it was felt to be useful. I think that this could possibly be a good compromise in the absence of a better solution.

> 
> 
>> I am guessing the answer might be no, as screenreaders tend to work on the OS level rather than the browser level, but I might be surprised.
> 
> Yeah, the Web page and often also the browser generally doesn't know
> that a screenreader is running (except when the screenreader is a
> browser extension itself), so anything along these lines is a bit hard
> to do.

This is a shame, but yeah, makes sense.

> We had been thinking about such a feature also for audio
> descriptions that would be read out by a screenreader at the same time
> that a video is playing and that requires both: a new API in the
> screenreaders and a new API in the browsers.
> 
> Would be worthwhile if somebody wants to attack this problem!

Could this be done as an extension of video text tracks/ functionality? There is already a metadata track type, which is not intended to be used visually on the page.