From:  Marco Zehe <mzehe@mozilla.com>
Date:  11 Nov 2015 19:45:22 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

Hi Chris,

again, on the mentioned platforms, it is not the browser that does the
audio ducking, it is the screen reader. So the browser, Music app, or any
other audio-producing application is forced into obedience by the screen
reader. You're talking about the reverse, which is technically tricky, to
put it mildly, since there is no way for the browser to detect when a
screen reader is running, much less when it wants to speak something.

Marco


On Wed, Nov 11, 2015 at 12:35 PM, Chris Mills  wrote:

> Hi Marco,
>
> Yes, this is exactly what Henny and I were talking about. Thanks for the
> clarification. It is really surprising that none of the desktop browsers
> have adopted the concept.
>
> Chris Mills
>  Senior tech writer || Mozilla
> developer.mozilla.org || MDN
>  cmills@mozilla.com || @chrisdavidmills
>
> > On 11 Nov 2015, at 11:14, Marco Zehe  wrote:
> >
> > Some screen readers, such as VoiceOver on the Mac and iOS, as well as
> TalkBack on Android, have a feature commonly called audio ducking. Since
> they know when they want to speak something, Apple created this concept
> where it turns down the volume of any other audio output when VoiceOver
> speaks. This first appeared on iOS, was then brought to OS X in Mavericks,
> and also got adopted by TalkBack on Android recently. On all platforms, the
> feature is on by default, but can be turned off if need be.
> >
> > For some reason, none of the Windows screen readers, including NVDA, has
> adopted this concept. I am also not aware whether Orca is doing this on
> Linux or not.
> >
> > Marco
> >
> >
> > On Tue, Nov 10, 2015 at 10:47 PM, Silvia Pfeiffer <
> silviapfeiffer1@gmail.com> 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 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. 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!
> >
> > Cheers,
> > Silvia.
> >
> > >
> > > Thanks,
> > >
> > > Chris Mills
> > >  Senior tech writer || Mozilla
> > > developer.mozilla.org || MDN
> > >  cmills@mozilla.com || @chrisdavidmills
> > >
> > > _______________________________________________
> > > accessibility mailing list
> > > accessibility@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/accessibility
> > _______________________________________________
> > accessibility mailing list
> > accessibility@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/accessibility
> >
>
>