1.4.2 Audio Control - Do two-way voice communications features and/or video conference features need to meet this req?

[goodwitch]

Curious question (because we are testing a web site that has two-way voice communication functionality AND video conference/meeting functionality):

Must a video meeting function (assume the video meeting function is inside a web page) need to meet:

1.4.2 Audio Control - If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.

Is the audio in a web based video or VOIP call considered "automatically playing"? Or, do we need to add a note to clarify that this requirement does not apply to web based VOIP or web based virtual meetings?

(Then I got curious...to see if browsers might give me a way to turn off the incoming audio. I'm working from a Mac...and here is what I experienced:

In one video mtg platform...I just tested to see if there was a way for me to mute the incoming sound.

• In Chrome, I could do it using browser based feature to mute a tab: https://www.wikihow.com/Mute-and-Unmute-Google-Chrome-Tabs
• In Safari, I found a similar feature...but when I tried to mute the tab..it didn't actually work when I was INSIDE the web based video mtg (but my ability to mute audio on a tab in safari DID WORK on a site like YouTube when I had a video playing).
  )

[goodwitch]

Is it valid to say, when a user clicks on a link or a button to open a VOIP call (in a browser) or a Virtual Meeting (in a browser) that they have chosen to "play the audio" and therefore 1.4.2 Audio Control does not apply (because the audio is not automatic)?

[patrickhlauke]

Is it valid to say, when a user clicks on a link or a button to open a VOIP call (in a browser) or a Virtual Meeting (in a browser) that they have chosen to "play the audio" and therefore 1.4.2 Audio Control does not apply (because the audio is not automatic)?

this is the rationale i'd use for this NOT to fail 1.4.2, yes

[mbgower]

This phrase in the Understanding document seems to cover this sufficiently in the context of a call or meeting activated by the user.

In the context of this Success Criterion, "plays automatically" broadly refers to audio that is not started/played as a direct result of a user's intentional activation. For example, not selecting a link or button.

If you'd like to add something more specific to this context, feel free to create a PR. Happy to incorporate. Otherwise, let me know if we're good to close this.

[goodwitch]

So...before I try to write something...let me make sure that you agree with the conflicting info I'm struggling with:

Test Case 1: webpage that auto plays background music

1. Go to this URL: https://merryxmas.ccbng.com/
2. Click on Low-Res (or High-Res) Button
3. Page loads with music already playing
4. I think this site fails 1.4.2 Audio Control

Test Case 2: web based meeting platform (could Zoom, WebEx, Meet...I'm going to define this test case using GoogleMeet because most of us have access to that...but my question obviously extends to any browser based video mtg platform or VOIP function):

1. Assumes you have a gmail account.
2. Open gmail
3. Click on the Google Apps icon (to open the modal/menu of google apps)
4. Click on the Google Meet icon
5. Click on the New Meeting button
6. Select "Start a New Meeting" from the menu
7. Google Meet Opens with incoming audio on
8. We are saying (in this conversation in this github thread) that this doesn't fail.

Do you agree that Test Case 1 fails?
If yes, then how can Test Case 2 pass (unless we add something to the understanding document that says: activating a link or a button to start or join a Video Meeting or VOIP Call is considered an intentional user action to have incoming audio turned on).

[mraccess77]

Wouldn't 1 pass if the audio mute button were accessible? Because there is a control to mute/stop the audio that seems acceptable to meet 1.4.2 if it was accessible.

[goodwitch]

So, in Test Case 1, the is no audio play, pause, or mute button available (for the incoming audio). The audio in test case 1 is autoplaying with zero controls for the user.

And, in Test Case 2, there is no way (within a meeting platform like Google Meet) to just mute the incoming audio. I can mute my microphone (mute myself). But I cannot mute all incoming sound from the digital meeting (from within the digital meeting platform).

[mbgower]

So, I'm going to suggest this as a possible addition. If it's getting close to what you're looking for, we can move it into a PR and wordsmith it into submission.

In the context of this Success Criterion, "plays automatically" broadly refers to audio that is not started/played as a direct result of a user's intentional activation. For example, selecting a link or button with clear labelling or context that it will start an experience where audio will play is an example of starting in response to a user's intended action.

[mbgower]

The other thought I had was whether audio really "plays" on a conference call. It doesn't really seem to meet the context of the SC.
That said, I think an ability to control the volume on a conference call is a useful feature to have, independent of system volume.

[alastc]

I think it makes sense to say that joining the meeting is not the same as "plays automatically", and even if it were, leaving the meeting would be a mechanism to turn off the audio. The proposed text seems to cover that scenario and others more broadly, so should help.

[bruce-usab]

Discussed on Backlog call 3/7. Mike volunteered to draft a PR clarifying the point, since web based live audio conferencing is common now. We can anticipate getting a similar question in the future