Source audio mute doesn't work with VoiceOver screen reader on macOS

[nebeker]

Operating System Info

Other

Other OS

macOS 12.3

OBS Studio Version

27.2.2

OBS Studio Version (Other)

No response

OBS Studio Log URL

https://obsproject.com/logs/U1Tpoa9RarzCDlAq

OBS Studio Crash Log URL

No response

Expected Behavior

When using VoiceOver, activating the mute checkbox on a source with CTRL+OPT+Space should mute an audio source.

Current Behavior

Checkbox changes state, visual icon goes from grey speaker with waves to red speaker with X, but source is not muted. Meter remains colored.

Steps to Reproduce

1. Open OBS
2. Start VoiceOver - CMD+F5
3. Move VoiceOver to "mute [source name] audio unchecked checkbox" - CTRL+OPT+Right arrow multiple times
4. Activate checkbox - CTRL+OPT+Space

Anything else we should know?

The current workaround is to simulate a mouse click, by pressing CTRIL+OPT+CMD+5 to move the mouse cursor to the checkbox and then CTRL+OPT+SHIFT+Space to simulate the click action. This is a workaround, not a typical or recommended usage pattern.
This is a result of the mute action being bound to mousePressEvent, instead of the standard stateChanged provided by QCheckBox. This bug is present in all QCheckBox based controls.

[nebeker]

To clarify, this bug also affects the start/stop streaming/recording/camera buttons, which are also checkboxes. Semantically, they should be buttons, but I assume they were based on checkboxes to inherit the text state behavior. This is not only confusing for a screen reader user, but also leads to this unintended behavior.

[RytoEX]

This is a result of the mute action being bound to mousePressEvent, instead of the standard stateChanged provided by QCheckBox.

To clarify, we do not use the mousePressEvent. The mute QCheckBox is linked to the clicked signal inherited from QAbstractButton (QAbstractButton::clicked()). While it may be possible to use QCheckbox::stateChanged() or QAbstractButton::toggled(), we suspect this is not a simple find-replace since the mute checkbox can respond to OBS hotkeys which could toggle the checkbox and cause the checkbox to emit those signals. Anyone who is trying to resolve this should be mindful of that when writing and testing a solution.

To clarify, this bug also affects the start/stop streaming/recording/camera buttons, which are also checkboxes. Semantically, they should be buttons, but I assume they were based on checkboxes to inherit the text state behavior. This is not only confusing for a screen reader user, but also leads to this unintended behavior.

These buttons are not checkboxes. They are QPushButtons:

• Start Streaming:

  obs-studio/UI/forms/OBSBasic.ui

  Line 1310 in 7cc2065

  <widget class="QPushButton" name="streamButton">

• Start Recording:

  obs-studio/UI/forms/OBSBasic.ui

  Line 1379 in 7cc2065

  <widget class="RecordButton" name="recordButton">

  
  

  obs-studio/UI/record-button.hpp

  Line 5 in dde4d57

  class RecordButton : public QPushButton {

• Start Replay Buffer:

  obs-studio/UI/record-button.hpp

  Line 14 in dde4d57

  class ReplayBufferButton : public QPushButton {

  
  

  obs-studio/UI/window-basic-main.cpp

  Lines 1675 to 1677 in 188347d

  	replayBufferButton = new ReplayBufferButton(
  	QTStr("Basic.Main.StartReplayBuffer"), this);
  	replayBufferButton->setCheckable(true);

• Start Virtual Camera:

  obs-studio/UI/window-basic-main.cpp

  Lines 1647 to 1649 in 188347d

  	vcamButton = new ReplayBufferButton(QTStr("Basic.Main.StartVirtualCam"),
  	this);
  	vcamButton->setCheckable(true);

They do, however, have the property "checkable" set to true, as observed here and above:

• Start Streaming:

  obs-studio/UI/forms/OBSBasic.ui

  Lines 1329 to 1331 in 7cc2065

  	<property name="checkable">
  	<bool>true</bool>
  	</property>

• Start Recording:

  obs-studio/UI/forms/OBSBasic.ui

  Lines 1398 to 1400 in 7cc2065

  	<property name="checkable">
  	<bool>true</bool>
  	</property>

As far as I know, "checkable" simply allows the button to act as a toggle rather than a button with no state.

What exactly is the "unintended behavior" that you're experiencing with these buttons? Have you checked through Qt's QTBUGs for anything that matches the behavior that you're seeing? I know there are multiple QTBUGs specifically related to VoiceOver, but I'm not aware of anything related to QPushButtons and the checkable property, off the top of my head. Not to say there isn't buggy or unexpected behavior with checkable QPushButtons and VoiceOver, but it would be helpful if such an issue were tracked on Qt's side.

[nebeker]

Interesting. I'm not familiar with the code base, or Qt, really, so I'm not surprised I din't get that quite right. That was my conclusion from going over the code for an hour or so.

I also made an incorrect assumption about the other buttons, based on the way they're announced by VoiceOver (ie. "start streaming unchecked checkbox"). Either way, I can't reproduce the behavior of the mute control. These were an afterthought and I didn't test them, like I did with that control. Sorry for wasting your time on them.

Going over the docs for QAbstractButton::clicked() it's not clear to me whether or not this is triggered by the keyboard, but turning on Full Keyboard Access [System Preferences - Accessibility - Keyboard] and tabbing to the mute control and hitting space reproduces the same unintended behavior I noticed with VoiceOver: the checkbox is checked, but the source isn't muted. That might be an easier way to verify and test this.

As far as user impact goes, keyboard users (sighted or blind) can't mute audio sources the same way mouse users can and, worse still, might thing they have, because the checkbox does change state.

Regarding upstream Qt bugs, I'm not sure that would come into play, because the checkboxes are working as intended: they change state when activated by the mouse or keyboard and surely send the stateChanged signal.

By the way, can this get the "Accessibility" tag?

And thanks for looking into this and providing those clarifications.

[RytoEX]

Going over the docs for QAbstractButton::clicked() it's not clear to me whether or not this is triggered by the keyboard, but turning on Full Keyboard Access [System Preferences - Accessibility - Keyboard] and tabbing to the mute control and hitting space reproduces the same unintended behavior I noticed with VoiceOver: the checkbox is checked, but the source isn't muted. That might be an easier way to verify and test this.

Regarding upstream Qt bugs, I'm not sure that would come into play, because the checkboxes are working as intended: they change state when activated by the mouse or keyboard and surely send the stateChanged signal.

On Windows 10, while running Narrator, pressing space bar while the mute checkbox for a source in the Audio Mixer is highlighted causes Narrator to read out that the mute checkbox has been checked. The audio from that mixer source will mute immediately in the output (file written to disk, in this case). It's possible that there is a Qt issue regarding VoiceOver or QAbstractButton::clicked() or a platform implementation difference between Windows and macOS where space bar (or CTRL+OPT+Space) activates QAbstractButton::clicked() on one but not the other.

As far as I can tell, if the UI for the mute checkbox has updated, the code to mute the source must have run. Have you checked the resulting output (a video file and/or stream) to see if the source's audio is actually muted in the output? I'm curious if this is just a visual issue with the volume meter not updating to grayscale.

[nebeker]

As far as I can tell, if the UI for the mute checkbox has updated, the code to mute the source must have run. Have you checked the resulting output (a video file and/or stream) to see if the source's audio is actually muted in the output? I'm curious if this is just a visual issue with the volume meter not updating to grayscale.

I figured this out, while a totally blind friend was testing live, on stream. They then recorded to disk and got the same results. I then recorded to disk myself and got the same results.

It sounds like it could be a platform specific issue, but it turns out it doesn't affect other buttons, so I think it's scoped to the checkbox controls. Are any other controls based on checkboxes, so I could test them?

I'd urge you to have this tested on macOS, either with VO or with keyboard full access. I don't expect you to take my word for it - I would want to verify a bug report too - but testing on Windows will not help.

[RytoEX]

It sounds like it could be a platform specific issue, but it turns out it doesn't affect other buttons, so I think it's scoped to the checkbox controls. Are any other controls based on checkboxes, so I could test them?

From a brief code search, it seems that the Visibility and Locked buttons in the Sources list (the eye and lock icons) are actually derived from QCheckBox. There are checkboxes in the Advanced Audio Properties dialog, as well as throughout the Settings dialog.

I'd urge you to have this tested on macOS, either with VO or with keyboard full access. I don't expect you to take my word for it - I would want to verify a bug report too - but testing on Windows will not help.

I do not have a Mac to test on, so that will have to fall to someone else.

I manually examined the code paths for how the muting is handled. I tested on Windows specifically to provide an observation of contrasting behavior on a different platform. This serves multiple purposes, such as isolating the scope of the issue by removing a platform from testing and debugging, and also to point out that this may yet be a Qt issue that is specific to macOS, because all of the code I examined is otherwise the same for all platforms. I asked clarifying questions to further clarify and narrow the scope of the issue being examined.

[nebeker]

(...) it seems that the Visibility and Locked buttons in the Sources list (the eye and lock icons) are actually derived from QCheckBox.

OK, I can't get to those by tabbing and with VoiceOver, I can get to the sources, but not the checkboxes. That's actually really surprising to me.

There are checkboxes in the Advanced Audio Properties dialog

I can't get to these with VoiceOver (same as #2502), but tabbing and arrowing there, visually works, and they seem to be working.

as well as throughout the Settings dialog.

These seem to work.

It looks like this might be the only checkbox with extended behavior, since the other act and look like regular form checkboxes.

I manually examined the code paths for how the muting is handled. I tested on Windows specifically to provide an observation of contrasting behavior on a different platform. This serves multiple purposes, such as isolating the scope of the issue by removing a platform from testing and debugging, and also to point out that this may yet be a Qt issue that is specific to macOS, because all of the code I examined is otherwise the same for all platforms. I asked clarifying questions to further clarify and narrow the scope of the issue being examined.

Gotcha, that's excellent. Again, thanks for taking the time to dig into this.

[gxalpha]

Small update on the situation here:

• On my machine, the situation appears to have improved a bit with recent updates to Qt (either in OBS 28 or 29) (or possibly macOS?). For me, it's now possible to just click spacebar (without the VO button) after selecting the button with VoiceOver (tested with mute and record buttons). However, confirmation on that from other people in this thread would be appreciated.
• As for the original issue here, that still persists. Pressing VO-Spacebar still makes the button change status but not trigger the action. I was able to create a minimal reproduction case for this and will report a bug to Qt in the coming days. Edit: Reported upstream as QTBUG-110737