Feature request: mute microphone command

[mltony]

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 to NVDA+Delete.

Describe alternatives you've considered

1. Windows 11 claims to have Win+Alt+K global 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.
2. Some Laptop manufacturers have a keystroke on the laptop, such as Fn+F4 for 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.
3. Using mute button in your particular VC application is typically too slow. The use case for people working in large IT companies is they are on mute during VC calls most of the time and doing something in other applications. Then someone calls them out on VC, and then the user needs to unmute quickly. Trying to alt-tab to 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

[Adriani90]

Thanks Tony. Just to note that nvda+delete is already assigned to object location reporting. How about nvda+shift+delete?

[mltony]

That's in laptop layout. In desktop lauyout object reporting is NVDA+NumPadDelete. We can assign to NVDA+Delete only with desktop layout - that wouldn't cause any conflicts. But in any case I am flexible.

[seanbudd]

I think this might be better to be unassigned by default, as many keyboards have a native key for this, particularly laptops

[mltony]

@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.

[cary-rowen]

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.

[josephsl]

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.

[Adriani90]

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.

[seanbudd]

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.

I think catching and reporting the microphone mute events is possible, but it's a bit complicated
#6427 (comment)

[dkager]

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?

[mltony]

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.
Pycaw library provides MMNotificationClient which can listen for exactly this type of event. However, even when I provide empty listener, NVDA crashes every time relevant event occurs, e.g. when I either adjust volume or mute microphone. I see nvda_crash.dmp file being created and I don't see any python stack trace int the logs, which makes me think this must be some sort of segmentation fault - or whatever it's called in Windows.
So what can I do with nvda_crash.dmp file? How can I debug this further?
Pycaw comes with example file that appears to work fine when launched as a standalone python script. I basically copied their example into NVDA. So this makes me think that there must be some difference in how NVDA works with COM, vs how pycaw expects to work with COM, but unfortunately I know too little about COM to diagnose this.
FWIW here is my crashing branch - if anyone wants to play.
Do you guys have any good ideas how can I investigate this further? @seanbudd , @CyrilleB79 , @XLTechie, @lukaszgo1

[mltony]

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.

[LeonarddeR]

@dkager wrote:

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.

I wholeheartedly agree with this.

[mltony]

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.

[lukaszgo1]

@dkager wrote:

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.

I wholeheartedly agree with this.

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?

[dkager]

Fair points. A few thoughts:

• Does Teams / Zoom / etc allow to set global hotkeys and/or is the floating window usually focused by default? If so, that could be a solution.
• If you mute the microphone through volume control, will Teams respect this? And the other way around, does the Mute-button in Teams actually mute the microphone system-wide? If the Mute-button within Teams is specific to that app it could actually get rather confusing if NVDA mutes it system-wide.
• If there will be a mic mute command, then I would also add a speaker mute command. This also has genuine use cases.
• Assuming the key command for muting the microphone is generally available and works in Windows without special drivers, then one could use something like SharpKeys to add a hotkey.

[LeonarddeR]

@LeonarddeR @dkager If you are so opposed to adding this could you please propose a reasonable alternative?

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.

[lukaszgo1]

Someone like @jcsteh guarded for this pretty well during his NV Access time.

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:

• Include some of the ad-on features into core or
• No longer break compatibility with add-ons yearly, and do so only when absolutely necessary ensuring user needs can be addressed by add-ons in a stable way. Incidentally if this gets done more time could be spend on development rather than code refactoring, or introducing features such as compatibility override for add-ons which introduction, honestly, is the best confirmation that the current system does not work well for anyone.

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.

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.

Most importantly, as soon as something is in core, it is NV Access' main responsibility to maintain it.

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.

[Adriani90]

@dkager

Does Teams / Zoom / etc allow to set global hotkeys and/or is the floating window usually focused by default? If so, that could be a solution.

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.
the floating window is not focused by default by NVDA and it is actually not really accessible.
Moreover, sighted people can place windows of multiple programs next to each other, so they can unmute or mute more than one application without changing the focus from one window to the other but only by clicking on the buttons. A blind person has to cycle through the open windows and focus the coresponding windows first.
However, I can see the controversial part of this, sighted people are also searching for a solution, see several conversations on Redit.
Here is a tool that can actually acomplish this:
https://github.com/bralexc/mute-unmute-meetings

If you mute the microphone through volume control, will Teams respect this?

Yes.

does the Mute-button in Teams actually mute the microphone system-wide? If the Mute-button within Teams is specific to that app it could actually get rather confusing if NVDA mutes it system-wide.

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.

If there will be a mic mute command, then I would also add a speaker mute command. This also has genuine use cases.

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.

Assuming the key command for muting the microphone is generally available and works in Windows without special drivers, then one could use something like SharpKeys to add a hotkey.

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.
@mltony given this tool is also something sighted people use, is it something you could do too for solving your use case? Otherwise I don't see a strong argument why this feature should be part of NVDA core if there is already a tool for it. That tool even allows you to define audio indication when the Microfone is muted or unmuted.

[LeonarddeR]

Someone like @jcsteh guarded for this pretty well during his NV Access time.

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:

* Include some of the ad-on features into core or

* No longer break compatibility with add-ons yearly, and do so only when absolutely necessary ensuring user needs can be addressed by add-ons in a stable way. Incidentally if this gets done more time could be spend on development rather than code refactoring, or introducing features such as compatibility override for add-ons which introduction, honestly, is the best confirmation that the current system does not work well for anyone.

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.

[dkager]

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.

[lukaszgo1]

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.

[Adriani90]

@dkager that's something for #3049. However, your particular use case does also affect sighted people. It is not specific to NVDA.

[Adriani90]

@LeonarddeR
just my 50 cents on general points:

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.

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?
I see your point and I think it is also very important to take a strategic decision here, but note that there are still use cases that really can be solved by having them in the core of NVDA. See for example the indent navigation feature or a word handling feature in NVDA.

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.

[dkager]

@dkager that's something for #3049. However, your particular use case does also affect sighted people. It is not specific to NVDA.

I was actually trying to construct a use case for adding these hotkeys to NVDA. :-)
And then I would say: either all or nothing. I.e. a PR created for this issue should also tackle #3049 IMHO.

[Adriani90]

@LeonarddeR

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.

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.
There is also a big frustration in different use cases where we thought standards will make things better, and lot of people put lots of energy in advocating for those standards, pushing mainstream developers for more accessibility. However, still many people don't follow certain standards like WCAG, propper Accessibility API usage etc. So I think the expectations to screen reader development will raise and we will have to think in more pragmatic ways sometimes.

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.

[Adriani90]

@dkager for this use case there is a tool already.
https://github.com/bralexc/mute-unmute-meetings

[lukaszgo1]

@Adriani90 Have you tested it? I have just looked at its code, but it seems to me it does several ugly things including:

• Matches the given program by its title which will not work well for Webex in a screen share situation
• To be able to mute / unmute it brings the application window to the foreground and then hides it, again resulting in sub-optimal experience when screen sharing.

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.

[Adriani90]

@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.
If the developers of that tool are very responsive to accessibility, maybe we can try pushing there for further development first before having this in NVDA core.

[Adriani90]

There is also power toys from Microsoft that provides a microfone mute command feature which is global.
For fairness reasons, sighted people wish alot such a feature as well, see this discussion:
microsoft/PowerToys#21473

[josephsl]

Hi,

A few things:

1. Discussion of overall direction of NVDA: unless NV Access says otherwise, I think the discussion we are having is a valid one. Any issue that brings up a use case of a screen reader that's not seen as traditional screen reading is bound to move toward this very discussion.
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. I do see Leonard's argument that there is a gradual shift in screen reader development philosophy, particularly for NVDA as add-ons are slowly being incorporated into the core screen reader feature set (I realize that I may have played a part in this shift). As for philosophizing discussion earlier, while we don't often talk about definition and nature of screen readers, I think it is okay to have a discussion like this from time to time (say, every few years), and the current discussion is one example of that (so, in some ways, we have indeed been philosophizing over the nature of screen readers without naming it up front).
3. Proposed compromise: as I noted in an earlier comment, if Windows and OEM's offered a more uniform way to query and report on status of microphones, then the implementation of this feature could be a bit simplified.
4. Transferring code from add-ons to NVDA Core: if Tony is willing to maintain the mic mute toggle feature after its inclusion in NVDA Core (to some extent), then I think we should offer a space for the upcoming PR to be tested; otherwise, I think an add-on solution would be better (when an add-on code gets merged, this means code authors are showing their willingness to keep an eye on it as long as they can and the code is documented).Hi,

A few things:

1. Discussion of overall direction of NVDA: unless NV Access says otherwise, I think the discussion we are having is a valid one. Any issue that brings up a use case of a screen reader that's not seen as screen reading is bound to move toward this very discussion.
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.
3. Proposed compromise: as I noted in an earlier comment, if Windows and OEM's offered a more uniform way to query and report on status of microphones, then the implementation of this feature could be a bit simplified.
4. Transferring code from add-ons to NVDA Core: if Tony is willing to maintain the mic mute toggle feature after its inclusio in NVDA Core (to some extent), then I think we should offer a space for the upcoming PR to be tested; otherwise, I think an add-on solution would be better (when an add-on code gets merged, this means code authors are showing their willingness to keep an eye on it in NVDA Core as long as they can; if the code author is no longer able to keep an eye on NVDA Core, the maintenance burden is reduced greatly if the code is self-documenting, and I wish we could devote a bit more time to documenting our own Python/C++ code whenever possible; and that also extends to Git commit messages, but that discussion and my overall thoughts on that at another time). In summary, transferring add-on code is a commitment, and one must do so willingly with the understanding that the code author and NV Access are collectively responsible for maintenance and upkeep of the newly merged code (and this commitment starts with the add-on code, mostly editing add-on code from the vantage point of NV Access staff and other NVDA Core contributors, and one practical step (and I seriously hope folks do this) is LINTING; commitment is easy and hard, mostly the latter, I admit).

Thanks.

[XLTechie]

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.

[jcsteh]

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.

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. :)

Most importantly, as soon as something is in core, it is NV Access' main responsibility to maintain it.

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.

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.

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.

[jcsteh]

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.

[LeonarddeR]

@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.

[beqabeqa473]

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

[cary-rowen]

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.
That's why @huaiyinfeilong created the AudioManager add-on.

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.

[CyrilleB79]

I fully support splitting the implementation of mute notification (or even mute state querying if needed) and the general mute command.
There are so much issues or PRs with endless discussions that are never completed or closed. And when I open one of them I do not want to work of them because I need to read again and again a lot of comments when only 10% are useful to design a solution.

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:

• quickly unmute to answer when you are asked something
• quickly mute when speaker and you are in the same room and feedback loop occurs
• quickly mute when you are working home and your child calls or cries without realizing you are working
• quickly mute when a disturbing sound suddenly bothers you and others (e.g. drill).

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:
I acknowledge that a per-app muting may be more desirable in some case, e.g.:

• other people can see if you are muted or not.
• you can have two opened calls with one being muted and the other not
  However, be able to quickly react is much more important. It may still be possible to use the dedicated mute command of an application if there is one (e.g. teams) for who is wanting to.
  Re the possibility of people able to see if you are muted or not, it's worth noting that even without NVDA, this information is not always available, e.g. when using a headset with jack plug and analog mute capability.

Why a default assigned gesture:
Because it allows to react quickly even when you have a new installation of NVDA.

Why in core rather than in an add-on or other dedicated tool:

• Because add-ons or other dedicated tools would need a separate approval from the IT admin in some workplaces.
• Because a turnkey command integrated in NVDA is better for non techy users. It's worth noting that intensive users of VC solutions are not necessary techy users (and vice versa), especially in professional environment

[Adriani90]

@LeonarddeR WROTE.

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

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.
Note that for these features there is no alternative out there. There is no alternative tool you can use to split NVDA from other sounds.
Also if we let them in an add-on, we will depend on the maintenance of one or few people. Having them in the core will make sure a wider variety of people will contribute to maintaining them and solving issues. This is the practice we see since many years.
Re sound split: in my day to day job I struggle a lot while having many calls and trying to make valuable notes. Speaking for myself at least, having this in the core will definitely boost my efficiency at work a lot and will lead to much less frustration on my side.
My NVDA version at work is being updated once in 1.5 years, so even if I were allowed to install add-ons, every API breaking change that is not backwards compatible will make this feature unusable.

[josephsl]

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.