Feature request: mute microphone command #16056
Comments
|
Thanks Tony. Just to note that nvda+delete is already assigned to object location reporting. How about nvda+shift+delete? |
|
That's in laptop layout. In desktop lauyout object reporting is |
|
I think this might be better to be unassigned by default, as many keyboards have a native key for this, particularly laptops |
|
@seanbudd, sure, I deleted default key binding. However as I explained in the original post, the button on the laptop is not really usable since there is no indication of whetehr the microphone is muted or unmuted. |
|
How to improve the discoverability of features that are useful but do not have gestures assigned by default is a problem, and people often only see new features in the change log. |
|
Hi, If only OEM's standardized on a specific key code or an action for microphone toggle, and if Windows provide events or notifications regarding this... As for discoverability, I think mentioning microphone toggle feature in the user guide would be a good starting point. Thanks. |
|
I think this will be documented in the user guide as soon as it becomes part of the core. But yeah there should be a special zone in the user guide which summarizes features with unassigned gestures. However, this is out of scope for this particular issue and should be discussed in a separate one. |
I think catching and reporting the microphone mute events is possible, but it's a bit complicated |
seanbudd
added
p4
|
Reporting system status, including muting/unmuting the microphone is definitely in the realm of screen reading. I'm not so sure about actually performing the action of muting/unmuting from within the screen reader. If this is implemented, it would be good to also write a few lines about the rationale behind it. For example, what about muting the speakers, turning off the camera, putting the PC to sleep, enabling airplane mode, etc? |
|
I am currenlty working on PR for this. I am trying to figure out a way to catch system notifications so that NVDA could announce microphone mute status even if muted via laptop key - for those laptops that have such key. |
|
Please disregard my previous comment - I figured out root cause. It turns out garbage collector ate my listener object. Once I stored it in a global variable - it works fine. |
|
@dkager wrote:
I wholeheartedly agree with this. |
|
Arguing what falls into real of screenreading sounds like philosophizing. And I don't like philosophizing, I am just trying to solve a real life problem that affects me and other VIP people around me. This also closes the gap between sighted and blind in terms of performing this particular action. That's the rationale. |
While I'm generally not too kin on introducing additional non accessibility related features into the core, I believe we should aim for giving blind users the same possibilities as their sighted counterparts. One case which I'm encountering quite often both back when I had remote classes at the university and now at work is the fact that I am unable to mute my microphone when screen sharing quickly. Sighted people have a floating window where this action can be performed in both MS Teams and Webex (probably other communication apps follow a similar design). To be able to do so from the keyboard I'm forced to either purchase a keyboard which has such ability or use a laptop where this works well - none of these additional purchases are required for sighted users. @LeonarddeR @dkager If you are so opposed to adding this could you please propose a reasonable alternative? |
|
Fair points. A few thoughts:
|
I'm not necessarily opposed to this. I'm however seeing a shift in overall philosophy in NVDA"s direction. Previously, it really was a doing one thing and doing it well screen reader, leaving all the "bloatware" to JAWS, and if one really insisted, to NVDA add-ons. Someone like @jcsteh guarded for this pretty well during his NV Access time. Now, we're like if something helps the community, let's throw it into core. That could be a legitimate change of strategy. However, I'd rather see long standing bugs being splashed than time being thrown into more and more core features that need to be maintained and potentially can introduce more bugs. Most importantly, as soon as something is in core, it is NV Access' main responsibility to maintain it. |
This worked only because until 2018 or so add-ons were mostly backward compatible - i.e. add-on written for NVDA 2012 was very likely to work in NVDA 2018. This is getting off topic, but assuming we can agree that NVDA without any add-ons is not really a productive tool there are two options:
This would be a reasonable complaint for a commercial product. For a FLOSS software such as NVDA, what is implemented depends to some extend on what interests community members with necessary skills. If @mltony would not have decided to add ability to mute a microphone, they will very likely not use this time to fix any long standing bug - they will simply not contribute at all simply because writing a different patch does not align with their interest.
It is hard to disagree with this. However when the newly introduced feature will turn out to be buggy and difficult to fix, it is likely NV Access will just revert it rather than spent their time on introducing a fix themselves. |
From my experience Only zoom and Discord allows the shortcut to be defined globally. All other apps provide shortcuts which work only when focusing the window.
Yes.
No, the hotkey in Teams mutes the Microfone only for the Teams app. I agree the system wide muting or unmuting of Microfone can be confusing if it is not documented properly.
In this case we talk about muting / unmuting the sound card, which is actually already covered in #3049 which indeed has a very obvious use case if people accidentally muted the sound card while NVDA was not running. But for more details see the referenced discussion in that issue.
For laptops that have a dedicated key for this sharpkeys might be a solution, but there is no general hotkey in Windows for muting / unmuting the Microfone. However, I think the tool I found on Github is quite useful and fits perfectly into this use case. |
I don't think that this is getting offtopic necessarily. In my opinion, these points reveal that this suggestion is not yet ready for a pull request, but that a strategic decision really needs to be made before enthusiasts start salivating and developers put time into a pull request that ultimately does not reach the finish line. |
LeonarddeR
added
the
blocked/needs-product-decision
|
Just for completeness, there is another use case for wanting to quickly mute the soundcard: if you're in a room with other people attending the same Teams meeting and there is one central speaker/mic somewhere in the room. If you don't join in the right way, Teams will insist your speakers be turned on and causes feedback loops. |
|
The main reason why I believe the discussion about what should and should not be included into the core needs a better place is that this particular issue has been triaged, so apparently NV Access decided this is something which deserves to be in the core. |
|
@LeonarddeR
I think though a discussion about new features is still very valuable, and I still think that the community has a strong power in deciding on an educated basis what should be part of the core and what not. I didn't see a feature merged into NVDA that is really out of scope for this project yet. Do you have any specific one in mind? In my view we should not discourage people in starting such discussions and proposing new features to the core of this project. If a feature does not depend on external libraries, dependencies or any other standards that need to be maintained, I don't see a huge burden if the use case is wide and clear for the users. But we need such discussions in order to make a well educated product decision easier. |
I was actually trying to construct a use case for adding these hotkeys to NVDA. :-) |
I don't really see a change in philosophy, I rather see a more active community, discussing UX design for blind users and arguing what makes sense and what is not really needed. I think lot more people are more educated in what a screen reader should do compared to many years ago and expected features are at least as long standing as some bugs out there. In the mid to long term some things might also need a significant redesign. Re add-ons, NVDA gets more popular every year, especially in companies using it for testing accessibility, or in corporate environments where people with disabilities are engaged. I think the current add-on environment is still too restrictive due to security concerns. In this case some really important features that a lot of people really need for their jobs, should be considered as part of the core. Note that accessibility is not what it was years ago. More and more countries in the world issue regulations on this, compliance rules and testing environments are evolving. So we should really take further development seriously, not only solving bugs. Otherwise we will be really left behind or will have to pay lots of money for commercial solutions. |
|
@dkager for this use case there is a tool already. |
|
@Adriani90 Have you tested it? I have just looked at its code, but it seems to me it does several ugly things including:
In general in a corporate situation this is yet one more tool a blind employee has to request approval for, whereas their sighted colleagues can just use the communication app as is. |
|
@lukaszgo1 not yet in detail, but I thought it is worthy sharing it first, I just found it and it was looking promising to me. |
|
There is also power toys from Microsoft that provides a microfone mute command feature which is global. |
|
Hi, A few things:
A few things:
Thanks. |
|
I am also not fond of this feature being in NVDA.
However, I have experienced what Tony describes in point 3 of the
justifications, and consent that it is a real issue that wouldn't otherwise
exist without blindness. On that ground, I have to agree with @lukaszgo1,
although Powertoys might be a good alternate solution we could suggest somewhere
instead.
I will say, that I would prefer that no keystroke was defined by default, if
this is to be in core.
That's just the active muting control. As far as the announcement of mute state
change, I am unquestionably fully in favor of that.
@LeonarddeR, with regards to people putting in these new features without
working on long standing bugs: I do understand that thinking--I've been thinking
it myself. I do believe, however, that we have to do better at competing with
Jaws, and stuff like what @mltony and others are doing is a part of that, as
much as it goes against the grain of what NVDA has been.
That said, it was always the core team, not the users, who promoted that
conservative philosophy. Ultimately, the users want "least pain", which leads to
the real question of what the most users want at the moment. Since 2020, that
has seemed to be least pain while interacting with VC apps.
I will point out something you likely know quite well, both from observation and
experience. People in a mostly volunteer coding community, have to actually care
about a specific bug, before they will put time into fixing it. That is, in
part, why those long standing bugs don't get fixed. They aren't bothersome to
enough developer types to get somebody to fix them. At least in some of the
cases. That is just the way things are, and I'm not sure that this can ever be
overcome.
I'm sure you have lost interest and stopped working on some PRs and issues over
the years, that remain bugs today. It is just the way of open source
volunteerism.
|
I did, yes, but I'm also learning more and more that there is a much wider variety of needs and use cases than I ever realised. What is "nice to have" for one user might be "essential daily functionality" for another. I still think we need to be very careful with this - it's a very slippery slope - but it is definitely worthy of discussion. The key point, as always, is being deliberate and intentional about decisions like this, rather than chasing shiny unicorns. :)
Of course, this is the flip side: who ends up being responsible when things go bad. If it's NV Access, there's going to be natural push-back on adding new features because NVA doesn't have the resources to manage that. If NVA are more permissive, then the responsibility is mostly on the contributor. And yet the contributors are mostly voluntary, so that's hard. There were multiple times during the development of WASAPI when I nearly submitted a pull request to just revert it because I didn't have the time or inclination to deal with all the fallout it caused.
But then users get upset because something they have come to depend on gets removed. That's reasonable, but it puts everyone in a difficult position. Again, this happened with WASAPI when I suggested just outright removing it... and that wasn't even NVA making the suggestion to revert. Now, more on topic for this issue: As has been pointed out, this challenge is not unique to screen reader users. Screen reader users might be slightly more disproportionately impacted, but it's unclear how much. It has been noted that there is a floating window in some apps, but keep in mind that the solution being proposed here isn't entirely equivalent. If you mute the microphone at the OS level, the app doesn't necessarily report that the user is muted to the app, which means that other participants on the call can't necessarily see that. I imagine that can matter in some cases. |
|
In the interest of moving this forward, I would suggest first focusing on implementing reporting of the microphone mute state, as that is less controversial and I think most would agree this is reasonable scope for a screen reader. This might have been less obvious previously, since the mute state wasn't always visible to sighted users, but I think it is now with the rise of video/voice chat apps. If the app doesn't show this, some computers certainly do, but neither are efficiently accessible for a screen reader user. We're going to need this anyway if we want to support toggling. I would tackle toggling of mute separately. That way, we don't block the easier-to-justify feature on nutting out the less-easier-to-justify feature. |
|
@Adriani90 wrote:
While a community indeed should have strong power, it is NV Access that steers the overall direction of the project. @josephsl has said valuable things about the add-on store, which makes it much easier to add extra features to NVDA with a single click. The discussion here is not whether the feature has value, because I think we agree on that. The question is whether a feature belongs in core or in an add-on.
Yes, Sound Split is one of these features where the impact concerns me, especially since sound split off doesn't necessarily mean that the feature is inactive, i.e. it seems to force the off state upon us. See also #16292 @josephsl wrote:
@jcsteh wrote:
Yes, this is certainly in scope IMO.
Personally, I'm very happy with the way VS Code is doing this, though there's also a shift there. For example, if you're writing Python, you need the Python extension and you can disregard the C++ one. Visual Studio Code has integrated audio cues into the editor and I think this is a nice accessibility feature, although it could just as well have been included in an extension that I would have liked to see as a recommendation, since I use a screen reader. Translating this to NVDA: Indent nav is an add-on that I use very often. Should this feature be in core? I could say "yes" because I use it daily. However, a large number of others do not use it. So I would prefer it to remain an add-on that might be recommended to me as a developer. Today with the add-on store, I think I would even say that about features like focus highlight, screen curtain. On the same grounds, I am also against the incorporation of Sentence Nav. Does that make me think it's a bad feature? Certainly not. it's just better suited as an add-on IMO. And if an add-on would be highly voted by community members, it should be listed as such in a recommended section in the add-on store. In that case, everyone who wants the feature can install it. It is up to the author to maintain it, it is only up to core to keep it maintainable. I'm undoubtedly demonstrating a conservative view of what should be in a screen reader, but I also sincerely believe that that would be a route that will remain much more manageable in the long term for both NV Access and the community. That said, we definitely need a way to stop the every year breakage in that case. |
|
As some people said, i am also not seeing a point in introducing a
mute microphone command.
This could be accomplished with numerous ways, however notification
about muting/unmuting mic should be good to go.
…On 3/12/24, Leonard de Ruijter ***@***.***> wrote:
@Adriani90 wrote:
> I think though a discussion about new features is still very valuable, and
> I still think that the community has a strong power in deciding on an
> educated basis what should be part of the core and what not.
While a community indeed should have strong power, it is NV Access that
steers the overall direction of the project. @josephsl has said valuable
things about the add-on store, which makes it much easier to add extra
features to NVDA with a single click. The discussion here is not whether the
feature has value, because I think we agree on that. The question is whether
a feature belongs in core or in an add-on.
> I didn't see a feature merged into NVDA that is really out of scope for
> this project yet. Do you have any specific one in mind?
Yes, Sound Split is one of these features where the impact concerns me,
especially since sound split off doesn't necessarily mean that the feature
is inactive, i.e. it seems to force the off state upon us. See also #16292
@josephsl wrote:
> 2. Separation of concerns: I think we should practice separation of
> concerns - let NVDA Core work on essentials of screen reading and
> resolving issues such as bugs, performance, and others, and leave others
> up to add-ons. Why did we spend months designing and implementing the
> add-on store? Because NV Access and the broader NVDA community believes
> and relies on add-ons.
@jcsteh wrote:
> In the interest of moving this forward, I would suggest first focusing on
> implementing reporting of the microphone mute state, as that is less
> controversial and I think most would agree this is reasonable scope for a
> screen reader.
Yes, this is certainly in scope IMO.
> I did, yes, but I'm also learning more and more that there is a much wider
> variety of needs and use cases than I ever realised. What is "nice to
> have" for one user might be "essential daily functionality" for another. I
> still think we need to be very careful with this - it's a very slippery
> slope - but it is definitely worthy of discussion. The key point, as
> always, is being deliberate and intentional about decisions like this,
> rather than chasing shiny unicorns. :)
Personally, I'm very happy with the way VS Code is doing this, though
there's also a shift there. For example, if you're writing Python, you need
the Python extension and you can disregard the C++ one. Visual Studio Code
has integrated audio cues into the editor and I think this is a nice
accessibility feature, although it could just as well have been included in
an extension that I would have liked to see as a recommendation, since I use
a screen reader.
Translating this to NVDA: Indent nav is an add-on that I use very often.
Should this feature be in core? I could say "yes" because I use it daily.
However, a large number of others do not use it. So I would prefer it to
remain an add-on that might be recommended to me as a developer. Today with
the add-on store, I think I would even say that about features like focus
highlight, screen curtain. On the same grounds, I am also against the
incorporation of Sentence Nav. Does that make me think it's a bad feature?
Certainly not. it's just better suited as an add-on IMO. And if an add-on
would be highly voted by community members, it should be listed as such in a
recommended section in the add-on store. In that case, everyone who wants
the feature can install it. It is up to the author to maintain it, it is
only up to core to keep it maintainable.
I'm undoubtedly demonstrating a conservative view of what should be in a
screen reader, but I also sincerely believe that that would be a route that
will remain much more manageable in the long term for both NV Access and the
community. That said, we definitely need a way to stop the every year
breakage in that case.
--
Reply to this email directly or view it on GitHub:
#16056 (comment)
You are receiving this because you are subscribed to this thread.
Message ID: ***@***.***>
--
with best regards Beqa Gozalishvili
Tell: +995593454005
Email: ***@***.***
Web: https://gozaltech.org
Skype: beqabeqa473
Telegram: https://t.me/gozaltech
facebook: https://facebook.com/gozaltech
twitter: https://twitter.com/beqabeqa473
Instagram: https://instagram.com/beqa.gozalishvili
|
|
For myself or users I know in the Chinese community (this also includes other screen reader users): Volume adjustment features regarding microphone, speakers and applications are indispensable. However, this feature request is a small feature for me, it is part of AudioManager and I will still use AudioManager. Certain add-on features were brought to screen readers just because the community wanted them, and it wasn't one person's preference. |
|
I fully support splitting the implementation of mute notification (or even mute state querying if needed) and the general mute command. I also support the general mute command but I acknowledge that it needs to be discussed. What is clear is that there are various situations where a blind person should mute or unmute his mic as quickly as possible during a VC meeting:
The key point here is how quick muting / unmuting will occur. Sighted people are very quick with the mouse, even if they need first to switch window. To be able to compete, the general mute command with a default assigned key is the best solution. Why a general command:
Why a default assigned gesture: Why in core rather than in an add-on or other dedicated tool:
|
|
@LeonarddeR WROTE.
I agree #16292 is a very crucial issue and if this is not solved it might lead to reverting the sound split feature. But I still think sound split as well as some other globally used features such as sentence nav or indent nav or word nav need to be in the core because they are widely used in the corporate environments where add-ons are often not allowed. |
|
Hi all, I think it would be best to discuss the overall direction of screen reading and add-ons in #16295 so we can focus on mic mute in this issue. Thanks. |
Is your feature request related to a problem? Please describe.
I would like to be able to mute microphone easily during online calls in Skype, Teams, Zoom and browser-based VC apps.
Describe the solution you'd like
NVDA keystroke that mutes/unmutes microphone.
I propose to bind it by default toNVDA+Delete.Describe alternatives you've considered
Win+Alt+Kglobal keyboard command to mute/unmute microphone. However that's not true. Quick investigation shows that it only works in Microsoft Teams. Ironically, it doesn't work in Skype, a Microsoft application too. There is evidence all over Internet that it doesn't work in a bunch of other VC apps. Even if it works in Teams, there is no spoken notification, so NVDA users won't know whetehr the mic is muted or unmuted, rendering this keystroke useless.Fn+F4for Lenovo. However this is not a good solution either, because again it doesn't trigger any spoken notification, and it doesn't work with external keyboards.alt-tabto the right application, and then finding the mute button in that application might take 10 seconds or even more - in practice that's enough for other people on the call to assume that the user has fallen asleep and move on. That's why I propose this new keystroke to quickly unmute the mic.Additional context
Prototype is implemented in Tony's enhancements add-on.
Prior discussion: #16037
The text was updated successfully, but these errors were encountered: