Before we get started, some important disclaimers. First, these are (as with everything I write) my own opinions, not the opinions of the company where I work. Second, while I have developed a couple addons for NVDA, I am a hobbyist developer. While I was deeply involved in cryptocurrency and all of the operational security implications tied up in it for six years, I am not a professional security expert, and I have no security certifications. I've used NVDA for over ten years, but I also can't call myself an expert in the NVDA codebase or the political internals of NVAccess or the pressures it's under.

This article is just a collection of decisions that NVAccess has made that have made me go "Huh. What?" Each one, taken on its own, is easy to brush off. But taken together, I'm worried that they reveal a pattern of rapid decision making, a lack of long-term thinking, and a focus on surface level problem solving and bandaging rather than tackling the underpinning issues.

Moving NVDA-Remote into the codebase

This was the first decision that gave me pause. NVDA Remote was originally developed as a third-party addon, funded via crowdfunding. However, users came to depend on it to do their jobs. But because it requires hooking deeply into the NVDA codebase, it was one of the addons that would stop working with every major NVDA release. So NVDA decided to bring it into the codebase directly, rather than preserving it as an addon. This had a bunch of advantages. In theory, it would mean that NVDA could reduce its API surface, because it could make private parts of the API that were used primarily by NVDA-Remote. It would also solve a major pain point for users, and reduce the complaints NVAccess would have to deal with. On the other hand, it increases the maintenance burden on the NVDA developers, doesn't make the complaints about addon deprecation go away, means NVDA-Remote can now only be updated with NVDA itself, and means anyone who wants to work on NVDA-Remote now has to understand the entire NVDA codebase.

It also sets a weird precedent. If enough users depend on your addon, does that mean it gets to be part of core NVDA? What features should be part of core, and what features should be an addon? What features should just be a different app completely? These are difficult questions, that require a lot of deep thought, and have implications for everything from what features NVAccess develops, to how it supports addons. I'm uncertain what NVAccess's answers to these questions are, or if they have even officially defined any.

These are tradeoffs that reasonable people can have reasonable disagreements about. But it was the first time where, as an outsider to the decision making process, I felt that NVAccess got it wrong. But I'm probably missing context, so I'll just have to trust that NVAccess knows things I don't.

on-device image description

During the switch to 64-bit NVDA NVAccess talked about, and released into beta, a feature to provide on-device image descriptions. It never made it into the official release for numerous reasons, not limited to the fact that it just didn't work particularly well. On one hand, alpha and beta builds seem like the perfect place to explore proof of concept features like this. On the other hand, so do NVDA Addons. NVDA provides a rich API for Addons to implement exactly this feature. In fact, addons that do this (both on and off device) already existed. The fact that AI inference code and the ability to download an image description model were being included in NVDA core made me go "Huh. What?" I wonder what features should be in core, and what features should be an addon? I wonder if and how NVDA has thought through this overall policy? Last I checked, it was still on the roadmap, so I guess NVAccess intends to try again.

One could argue that "users want it, and every other screen reader has it" is a good enough reason that it should be part of core NVDA. But not every other screen reader supports addons the way NVDA does, and the majority of other screen readers are closed source and impossible for users to customize at all. So users can only have what the developers give them. With NVDA, that's not the case at all. While I personally remain unconvinced that "users want it", I have to assume that I'm wrong, and NVDA has data here that drove them to do this work in core rather than as an addon. I'll just have to trust that NVAccess knows things I don't.

The 64-bit migration and the 32-bit bridge

With the release of NVDA 2026.1, NVDA has migrated to being a 64-bit application. For addons that require loading 32-bit dll files (synthesizers, Braille display drivers, or anyone else using any 32-bit library), this means that our addons need to load those libraries into a 32-bit process and communicate with them via IPC. Originally, when talking about the roadmap, NVAccess communicated that they intended to release a compatibility bridge that addon developers could use. They then clarified that this bridge would only be available for synthesizer addons. Now, they're talking about a secure addon API for synthesizers. But NVDA 2026.1 was released, and the compatibility layer/bridge isn't here. That means that developers who want to keep our addons working need to write our own compatibility layers. But some sort of bridge from NVDA is still on the roadmap, apparently. But now that developers have all gone to the work of making our own compatibility layers, why should we switch to the NVDA one if and when it comes out? That just means even more work for us.

Personally, when I read about NVDA's plan to develop a compatibility layer to allow loading of 32-bit DLLs, I said "Huh. What?" that sounded like a lot of work. Clarifying that it would only be for synthesizers made the workload seem more reasonable, but as I looked at the issues and commits on GitHub, I was seeing 2026.1 head closer and closer to beta, with no work on any kind of 32-bit compatibility. So I decided to just bite the bullet and do the work myself to keep my own addons working. However, I know at least one developer held off, believing NVDA's communication that it would create a compatibility layer for addon developers to use. When it became clear that it wasn't going to do that, at least not for 2026.1, they had to scramble and quickly write there own.

A 64-bit migration is hard! And NVDA had no choice but to get it done. But I'm not sure why 2026.1 was released without the promised compatibility layer. Honestly, I'm not even sure the layer should have been promised; does this belong in core? Every addon is going to interact with the 32-bit libraries it needs differently. IMHO, having addon developers create the compatibility layers we need on our own seems like the right decision. But I wish it felt like something that was decided and communicated, rather than something that just happened. But I'm probably missing context, so I'll just have to trust that NVAccess knows things I don't.

The Journey Of The Add-on Store

Back in the day, NVDA had an add-ons repository. It wasn't built into NVDA; it was just a directory listing available addons for download. However, this directory had one major problem: submitting to it was annoying. You had to go through a strict code review, and even meet NVDA style guidelines before your addon was accepted. As an addon author myself, I was part of the problem. I never bothered to submit to the official add-on repository because it was just too much effort.

Eventually, NVDA create an add-on manager built into NVDA. It allowed users to browse, download, and install addons. But it didn't allow updating all addons at once when it was initially released. It also couldn't automatically keep all addons up to date on initial release. These feature oversights made me go "Huh. What?" But this addons list was still based on the official, hard to get into, addons repository.

Around this time, the Spanish NVDA community created nvda-addons.org, an excellent website listing a large variety of addons for download. Each submission was reviewed by a human, but the review and submission processes were much easier. The Spanish NVDA community honestly deserves enormous respect, and an enormous shout-out, for the work they did here. For the first time, we had something centralized where we could go to find addons. And the balance of human review felt about right.

And then NVDA released their brand new Addon Store. No more annoying and difficult code reviews! Now, an addon would be reviewed the first time it was submitted, and future updates would be entirely automated! And the only review done would be a basic review to make sure the developer seemed okay. Rejoice! We could now all submit our addons to the store! Well, except for IBMTTS or Eloquence or DECTalk or bestspeech, for intellectual property reasons completely beyond NVDA's control. So everyone was still probably installing at least one (maybe more) addon outside of the store. Of course, nvda-addons.org continued listing those addons.

I wonder why NVDA decided to develop its own addon store, when the community had already solved the problem? I wonder why it decided to drop those annoying code reviews, rather than keep the official addon store continuing to demand a much higher bar for addon developers, and allowing us lazy amateurs (like me) to just submit to the less trusted nvda-addons.org? I'm probably missing context, so I'll just have to trust that NVAccess knows things I don't.

Magnification On The Roadmap

Freedom Scientific has had a lot of success with Fusion, a product that combines zoomtext and jaws into a single app. At the same time, there is no high quality open source magnifier available on Windows. So obviously, NVDA should add a magnifier! How much work can it really be? My own answer is: I have absolutely no idea, but probably "more than it seems." An open source magnifier should absolutely exist! And it should absolutely be a priority! Maybe it should even be done by NVAccess. Should it be built into NVDA? Does NVAccess have the resources it needs to do a good job on screen magnification (both in funding and user experience expertise)? I don't know. I just hope it's on the roadmap because it makes sense, not because Freedom Scientific did it first. But I'm probably missing context, so I'll just have to trust that NVAccess knows things I don't.

The Secure Addons API

Also on the roadmap: a lot of talk about a secure addons API, and changes to addon security. What does any of this mean? What directions is NVAccess thinking in? How might this be shaped? Where are these things being discussed, and how can addon authors influence what it might look like before any code gets written? I don't know. I'm probably missing context, so I'll just have to trust that NVAccess knows things I don't.

Scanning Addons With Virus Total

This is the thing that inspired this entire post. And I'll be honest, here: I screwed up. On launching NVDA, I saw this error in my logs:

'scanResults': {'scanUrl': 'https://www.virustotal.com/gui/file/2a83b713e38596cfbcb3f98b5eb91530ddfd0e9319907c6119cbbbe08f7acc88', 'malicious': 0, 'undetected': 67, 'harmless': 0, 'suspicious': 0, 'failure': 0, 'timeout': 0, 'confirmedTimeout': 0, 'typeUnsupported': 9}}

Traceback (most recent call last): File "addonStore\models\scanResults.pyc", line 31, in fromDict KeyError: 'virusTotal'

I then checked my firewall logs in my router, and saw that several connections had been made from my computer to virustotal.com. Naturally, without looking much further, I first assumed that NVDA was submitting all of my addons to virustotal.com for scanning. It turns out, though, that these two things were unrelated, and I corrected my post about the issue on Mastodon. But it drove home to me just how much trust I had lost in NVAccess, as I no longer worked under the default assumption that they had thought over all of the privacy and security implications of anything they did.

And to be frank, I still don't believe that they have thought them through. Why are they scanning addons with virustotal at all? Any addon can download and execute any code it wants. So if an addon is malicious, it's not going to send the malicious payload to the addon store for scanning! If a user has a malicious addon installed, it can modify the virustotal results inside NVDA itself, so they can't be trusted, even if they were worthwhile. An addon downloaded from outside the store can just create its own virustotal info and feed it to NVDA, for NVDA to do...whatever it does with that information. So at best, the NVDA Store scanning addons with virustotal.com does nothing. At worst, it gives users a false sense of security; I struggle to believe that an inexperienced user understands the difference between "Virus Total found no viruses" and "this addon is safe for you to install and use". But I'm probably missing context, so I'll just have to trust...you know what? No, I won't! This is a silly idea, seemingly implemented with no thought to the threat model it's defending against. While it has the wonderful property of not inconveniencing even a single user, it also has the less wonderful property of not inconveniencing a single attacker.

When I had this conversation on Mastodon, the response from NVAccess themselves was: "I really cannot stress enough how irresponsible it is to have a discussion about what you believe may be a security hole - in ANY software - on a public forum." I'm really not sure that the fact that the entire thing seems like poorly designed security theatre, and I don't understand what threat it's even defending against, is a security hole that should only be discussed in private. That smells like security through obscurity, with a dash of NVAccess not wanting criticisms of its decisions in public.

NVDA seems to be diving pell-mell into an addon security battle that the likes of Microsoft, Apple, and Google haven't been able to win. It seems to me that it shouldn't be playing that game at all. There are other trust models that can be explored, and other security wins that can be had. But these things will only come to fruition if NVAccess gets beyond the "We have to do something, and this is something, so let's do it," style of thinking that I'm terribly afraid NVAccess has been demonstrating all too frequently, of late.

Conclusion

One of the hardest lessons I've ever learned in the course of my career, and one I still struggle with to this day, came from one of the founders of the company where I work. Paraphrased from one of the many, many ways he stated and restated it to me over the years: "Focus on understanding the problem before you even think about the solution. If you don't, you'll end up solving the wrong problem." Jumping to solutions is human nature, and is one of the hardest things to resist. But sometimes, if you're not sure what to do, the best thing you can do is nothing at all. In this post, my intent was not to micromanage and criticize NVAccess. Rather, I'm trying to demonstrate a pattern of doing things because things must be done, that NVAccess seems to have fallen into. If you're an employee at NVAccess, I'm not trying to pressure you into re-litigating every decision you've made over the past three years; if you take anything at all away from this, I hope it's the overall pattern, not each individual decision. NVAccess has a lot of hard problems: addons, security, limited resources, planning and communicating out in the open, keeping up with accessibility changes, keeping up with its better-funded commercial competitors, and keeping users satisfied. It deeply concerns me that NVAccess is more and more reactive, not proactive, and that as an outsider I'm not seeing signs of it doing the deep thinking that will keep NVDA the maintainable, industry-leading, revolutionary program that it is currently. And we desperately need it to stay the course. Every single thing I've written above might be completely and totally wrong. But speaking personally, "Someone must know something I don't, so I'd better just trust them," can only go so far.

I'll close with this final thought: while NVAccess the organization is a nonprofit headquartered in Australia, NVDA itself is an open source product with a dedicated, determined, and smart community of employees, volunteers, users, and developers behind it. I don't know how to solve the problem I'm highlighting, and I don't think there are any easy answers. But in a real way, we are NVAccess, and NVAccess is us. We can all embrace the hard problems, and we all have a part to play if we want NVAccess to be the deeply thoughtful, sustainable, and long-term organization we need it to be. It could involve giving money, to allow NVAccess to have the resources and environment that fruitful thought requires. It could involve getting on the mailing lists and participating in the process, if you have the time. Or it could just involve productively making your voice heard: state thoughtful positions, listen, admit when you're wrong, and push back when you're still convinced you're not. And, perhaps a harder challenge, be open and vulnerable enough to do all of that in public.