Conversation

Notices

1. Embed this notice
   Tyler Spivey (tspivey@dragonscave.space)'s status on Wednesday, 19-Mar-2025 18:07:49 JST Tyler Spivey

   NVDA Remote was merged into NVDA for the upcoming 2025.1 release.
   This sounds like something to be happy about, but read on.

   Now every new feature and change has to go through NV Access to get approved, which is a lot more work than adding your feature to an addon.

   Why not create a separate addon? As said in #17703, they plan to remove the ability for addons to run on secure screens in the future. If this happens, nothing like Remote can ever be created again without the blessing and cooperation of NV Access.
   Instead of empowering developers and users by allowing them to choose which addons are usable on secure screens, NV Access plans on disabling them.
   Merging this just gives NV Access more leverage to meeting this goal. Their reason might be something like now that Remote is merged, we don't need addons there anymore because the interaction time is so short.

   You might say that NVDA is open source, so someone can just modify the features they don't like. That's true, but it has to be signed for UI Access to work correctly, so someone would have to pay quite a bit to fork it and do their own thing. You then also have the problem of a fragmented community between NVDA and the new one.

   The advantage with Remote merged in is that the users will be able to use Remote without an extra download, but we're going to be stuck with whatever NV Access gives us. I guess we'll see what they turn it into.

   • Embed this notice
     NV Access (nvaccess@fosstodon.org)'s status on Wednesday, 19-Mar-2025 18:07:44 JST NV Access

     in reply to

     • Brandon Tyson
     • Darrell Bowles
     • Svenja

     @svenja @vol4life8657 @BTyson @tspivey We aren't disabling add-ons on secure screens. If @tspivey had raised any concerns with us, we could have explained, but please see our reply here: https://fosstodon.org/@NVAccess/114187262027039287 Please follow us for OFFICIAL information, and remember you can now also sign up to updates like our blog via email: https://eepurl.com/iuVyjo

   • Embed this notice
     Svenja (svenja@mstdn.games)'s status on Wednesday, 19-Mar-2025 18:07:46 JST Svenja

     in reply to

     • NV Access
     • Brandon Tyson
     • Darrell Bowles

     @vol4life8657 @BTyson @tspivey @NVAccess I agree on that. i want to continue being able to hear my prefered Speech on every Screen.

     GreenSkyOverMe (Monika) repeated this.
   • Embed this notice
     Darrell Bowles (vol4life8657@tweesecake.social)'s status on Wednesday, 19-Mar-2025 18:07:47 JST Darrell Bowles

     in reply to

     • NV Access
     • Brandon Tyson

     @BTyson @tspivey @NVAccess I fully concur with all the points mentioned. I will refrain from updating my version of NVDA should this transpire. Although integrating NVDA remote as a component of the primary NVDA package might seem beneficial, the resultant compromise is not advantageous for the end user. It is almost as if the argument is that they will be provided with NVDA remote and other crucial add-ons deemed important, but are restricted to downloading add-ons solely from the specified add-on store, and your only screen reader open to you is NVDA at startup. I acknowledge that the latter point is somewhat exaggerated, however, in my view, there should be no reason for users to be restrained from using their preferred speech synthesizer on the UAC screens or at startup. From a user's standpoint, even contemplating such an idea is illogical.

   • Embed this notice
     Brandon Tyson (btyson@dragonscave.space)'s status on Wednesday, 19-Mar-2025 18:07:48 JST Brandon Tyson

     in reply to

     • NV Access

     @tspivey I wanted to mention @NVAccess on this so we can discuss this as I'm not in favor of completely disabling add-ons on secure screens at all and I will not update my NVDA if this happens. Apart from Remote, we need to think about people who prefer a certain speech synthesizer due to, for instance, hearing loss, or cases where the built-in synthesizers do not have very good language support for a given language (for instance, I heard that eSpeak has some foreign languages that are not good at all and there are some OneCore voices that also do not have high quality support for certain languages). Please consider these points before enforcing the inability to use add-ons on the secure screens. The correct approach is to either allow the add-on developer to indicate in the manifest whether the add-on is allowed to run on a secure screen, or to allow a user to individually select which add-ons to copy to the secure screen. The fact that the plan is to just completely disable all add-ons on the secure screen, instead of allowing users to selectively copy add-ons over to the secure screen, when users express that they want this, is not good and it is not in the user's best interest. I am hoping that this thread can start a dialogue about this so that this can be discussed further, as opposed to completely disabling add-ons on the secure screens without considering the possible ramifications.