@fastfinge Very interesting read, and thanks for putting it together. In particular, the "on-device image description" section piqued my interest as I thought, and mentioned several times on Mastodon, that with such a poor output quality, it shouldn't have found its way into alphas in the first place.
@amir I agree. But I do think it was worth exploring. In the same way I wrote my proof of concept AI text to speech addons. Without actually making them, I wouldn't have fully understood what a bad idea that is, and why it's a bad idea. I would have loved to see NVDA develope a prototype on-device image description addon. Then maybe realize it wasn't good enough and scrap it. But of course, as an addon, someone else could pick up the work if they thought they could salvage it. Because it was in core, now it's removed, and nobody else can hack on it even if they want to.
@fastfinge Agreed. But I even faced difficulty, and soft criticism, communicating the poor output of the feature to NVAccess. I was under the impression that they wanted me, and others, not to expect much from a feature like that, while praising its privacy-focused, on-device aspects.
@amir Yes. And I experienced hard criticism for even discussing a security feature in public. This, too, is a problem. Is NVAccess under funding pressure? Are they struggling to get grants, and public criticism of them is endangering that? Repeat it with me, everyone: I'm probably missing context, so I'll just have to trust that NVAccess knows things I don't.
@pixelate@amir I mean, if I had found a way to create an HTML file that would cause NVDA to delete all of your files whenever you opened it, I would agree that security through obscurity is, in fact, the way to go. Disclose that privately and let NVAccess fix it. But I can't agree that discussions of the design of the entire security system can, or should, take place in private.
@fastfinge Honestly, I was also flabbergasted by their message and intolerance! After all, you were not exposing a security vulnerability or hole. You were talking about a feature being promoted as a security measure, while it might not achieve the promised goals.
@fastfinge@amir No you are welcome to criticise publically - where it is warranted. You came out yesterday, guns blazing with random thoughts which were completely wrong. We've never shied away from open discussion, but unfounded and completely wrong assertions don't help anyone.
@NVAccess@amir And the assumption that were wrong I and others had corrected long before you got involved. The rest you declined to speak to, other than to complain that the discussion was public.
@amir@fastfinge Not at all. You were clear with your criticism, and we appreciate that. We never said not to expect anything, just that an on-device solution for that is ALWAYS going to produce simpler results than a cloud based model. We tried it, we couldn't get satisfactory results, we put it on hold, and actually I believe someone is looking at picking it up (just because it wasn't an add-on doesn't mean someone else can't jump in and help) so we may yet get somewhere with it.
@NVAccess@amir In an addon perhaps. Nv speech player was tested that wway. It didn’t work and was dropped. Someone else picked it up, and it lives on to this day.
@fastfinge@amir Sure, but making something an add-on vs in core is the same amount of work (if we're doing it at least, it will be done to same standard)
@NVAccess@amir Good to know. Again, I tried hard to present both sides of every decision. They are all decisions I think are incorrect, but reasonable people can draw different conclusions on them. What I’m not seeing is the discussion, or the reasoning. This is a notable change over the last few years. And during that time is when, after many years of making decisions in public, I started feeling like maybe I wasn’t thrilled with some of the decisions I could find little to no public discussion of. As I’ve said multiple times in this thread and the article, it’s possible I’m wrong about the patterns I’ve noticed. But I’m getting nervous. As, seemingly are others.
@NVAccess@amir I did what I do for any open source project. I checked the GitHub and the mailing lists. Largely I found these things being done as though the discussion about what should be done happened somewhere else. Now it was time to execute.
The community can do so much. Take some of my add-ons for example, I can no longer update them due to contractual obligations, and no one stepped up to maintain any of them. Those who rely on my add-ons are left in the dark, and I cann't do anything about it other than encourage people to fork. NVAccess throwing it's weight behind a feature makes me put more trust on it. @fastfinge @NVAccess
@mush42@fastfinge@NVAccess You did piper, right? We've been able to get it working in 2026.x builds, so we could keep using it. Now my wife and I have voices made by Derek Lane that sound like us for people to use. My friend @jakobrosin made the addon work, so yep, people have stepped up and they float around gently in the online currents, not forgotten.
@FreakyFwoof@mush42@fastfinge@jakobrosin I had a query just before about Piper, there is definitely still interest in it. Andre, if you've forked it or made a working version Musharraf is happy with, I'm sure the community would be happy to have a way to get hold of it!
@FreakyFwoof@NVAccess@mush42@fastfinge@jakobrosin I still like Piper. On Android there's a piper app called BookFusion which uses the same voices as Sonata/Piper. I sometimes wished I knew how to port things from one platform to another, oh I have coded a few things myself, but mostly classic DOS-games that I played as a child with my sister...but I may grab this new Piper fork from your site Andre, thanks
@mush42@fastfinge@NVAccess@FreakyFwoof Aha got the fork! Someone made a pull request well a fork of Sonata so it could work with the latest NVDA plus fixing voice download issues github.com/mush42/sonata-nvda/pull/72 if you could test it or if the user/developer is here in Mastodon that could be a plus. I'm also worried about the framework itself
@fastfinge And this from Microsoft Edge: "The connection for this site is not secure stuff.interfree.ca sent an invalid response. ERR_SSL_PROTOCOL_ERROR"
@VE3RWJ I'm not sure what's up on your machine. I just checked: stuff.interfree.ca resolves to 207.90.194.199
The certificate should be trusted by all major web browsers (all the correct intermediate certificates are installed).
The certificate will expire in 85 days.
The hostname (stuff.interfree.ca) is correctly listed in the certificate. Common name: *.interfree.ca SANs: .interfree.ca, .rblind.com, interfree.ca, rblind.com Valid from May 15, 2026 to August 13, 2026 Serial Number: 06a09afa07f5130433af0509623757306f2d Signature Algorithm: sha256WithRSAEncryption Issuer: R13
Common name: R13 Organization: Let's Encrypt Location: US Valid from March 12, 2024 to March 12, 2027 Serial Number: 5a00f212d8d4b480f3924157ea298305 Signature Algorithm: sha256WithRSAEncryption Issuer: ISRG Root X1 www.sslshopper.com/ssl-checker.html#hostname=stuff.interfree.ca
@fastfinge Hmm, I daily drive remote and don't mind whether it's core or addon, but that feature alone is invaluable. Did it need to be core? Probably not. Is it better for it in my personal view? Possibly. Did the 2026.1 issue where, if your network wasn't ready in-time, you jus wouldn't fail to connect to a server cause me some problems? Yes. Could it have been solved if it was still an addon? Yes, with 3 minutes with Codex/<insert LLM here or programming knowledge if you're cooler than me> Core, I just didn't touch it. I waited and hoped it would get solved and 2026.1.1 might have solved it. I haven't rebooted recently to find out. Remote on the whole though, absolutely necessary. The rest of the article, no real comment. Haven't been adversely affected.
@FreakyFwoof I completely agree that it's required. But does that mean it should be in core? I dunno. Like I say, reasonable people can disagree. But I notice that Apple has started moving apps (apple sports, apple invites, etc) out of the main OS so they can maintain and update them seperatly.
@fastfinge@FreakyFwoof IMO, putting it in core just shows how unserious NV Access is about the enterprise market. If they go on like that, they won't be displacing JAWS anytime soon. We need a RedHat of accessibility technology, because NV Access clearly aint that.
@FreakyFwoof@miki The more remote connections a screen reader makes, and the more possibilities it provides for an outsider to take control of a corporate machine, the harder it is to get corporate security people to let you install it. Jaws tandem had to solve the same problem, though.
@fastfinge@FreakyFwoof@miki Remote is disabled by default, needs to be deliberately enabled, and is readily blocked by running NVDA in secure mode. Please explain how that is less secure than the similar offerings by other screen readers? Then tell me how those other screen reader can run while being completely blocked from the internet the way NVDA can if you don't trust it?
@FreakyFwoof@fastfinge Enterprises are deeply paranoid about software that can control your computer, and every screen reader can. If it lets employees install completely unapproved addons that run with screen reader permissions, and can potentially exfiltrate data to a random server somewhere, it's a no go. Especially if there's no vendor to take the blame if something goes wrong.
@miki@fastfinge OK this is interesting. @ednun_p uses it on his work machines and some of the stuff he does I believe it's fair to say is highly, highly sensitive. I wonder how that plays out in that case?
@miki@fastfinge@ednun_p Also companies could just block that port as many do, I'm sure tandem also has a blockable port as well, thus, no data going anywhere... Hopefully...
@miki@FreakyFwoof So wouldn't having it in core be better, in that case? That way remote access still works without employees having to install addons. Or would it be worse, because remote access now can't be disabled? I don't know enough about the corporate environment to know either way. But I'm starting to wonder if NVAccess does, either. This is my entire point: these decisions are hard, and require deep thought and deep study, both to make the best possible decision (there are no perfect decisions) and to understand how you got there.
@FreakyFwoof@miki Right, but I am the one who decides if it gets enabled or not. Once NVDA is installed, the corporate security people have no control over that. But NVDA does have a corporate mode that disables addons.
@fastfinge@FreakyFwoof Disabling addons is not an option if you do genuinely need some, for example to make some internal piece of software accessible, or even to give your employees a better speech synthesizer than what Microsoft offers by default. What they should be doing is a group policy option to control which addons can be used and from where. This would allow you to place the allowed addons in a directory that the user has no write permissions for. This doesn't fully solve the problem because your addons still need to be GPL and you need to ship source code, making it much harder to develop and sell expensive enterprise addons for extensive enterprise software, but it's at least a step in the right direction.
@miki@FreakyFwoof Yes, this is another factor. But once again: jaws tandem is built in. Why is NVDA remote different? Again, I'm not sure what I think here. But I do know that the question is complicated.
@fastfinge@FreakyFwoof Right, but it's Apple and we know that they will take care of those apps in due time. With the Remote add-on in particular, I mean the original Remote, it was oftentimes updated terribly late as if it had been ditched by its own devs altogether.
@amir@FreakyFwoof Could NVDA have taken over maintaining the addon, but not have made it part of core? That way, it could be updated separately from NVDA. Maybe that would have made maintaining it harder somehow? I don't know. To repeat myself again: "I'm probably missing context, so I'll just have to trust that NVAccess knows things I don't." That phrase is doing far too much work, I think.
@amir@FreakyFwoof And the idea that "We've never done it that way, because we don't do that, so it can't be done." is another alarming sign of shallow decision making. Also, NVDA has never moved an addon into core. So they're already doing things they've never done before.
@amir@fastfinge@FreakyFwoof Great discussion - anyone care to ask US why we brought NVDA Remote into core? No, ok carry on then....
(If anyone IS interested), as Samuel guessed in his article, it helps simplify the API and security bringing that into core and also allowing you to have it run on startup without allowing add-ons to run at login, etc, etc.)
@fastfinge@FreakyFwoof@amir If only there was someone you could ask about why NV Access has done things..... If only NV Access themselves were contactable and able to answer questions.....
@FreakyFwoof@fastfinge Remote being core makes sense to me. The idea of getting someone who needs remote support, sometimes right now* to install an addon when they might not even know what an addon is is just causing more problems before a solution
@fireborn@FreakyFwoof I'm not sure I disagree with you. But to play devil's advocate, should a user who isn't technical enough to install an addon have a feature built into their screen reader that can allow another user to take full control of their machine? They could easily be tricked into giving control to someone they shouldn't.
@fastfinge@FreakyFwoof If this is the stance, though, then screen sharing should be removed from Mac OS, and quick assist should be removed from Windows.
@fireborn@FreakyFwoof I mean, based on the number of times my elderly family members get called by a nice man at "The Department of The Microsoft Windows", I could see potentially making that argument. I'm not sure I would, but...like...if you assigned it to me in debate club, I could defend it vigorously.
@FreakyFwoof@fastfinge The 2026.1 issue with automatic disconnection could just as easily have happened in an add-on. It was implemented to make things more consistent, no-one picked it up in alpha, and we've now fixed it in yesterday's 2026.1.1 update.
@fastfinge@FreakyFwoof Sure, but the reverse argument could be made if the add-on (compatible with 2026.1) is not available the moment the .1 release is out.
@fastfinge I have an opinion on this that might not be entirely popular: I think it'd be nice to have a screen reader that has nothing built into it. Kind of like how Linux is just the core, but you can interface with that core, in this case using extensions. No better way of solving the 'should it be in core' problem than to make nothing be part of it. Of course, that does cause other problems, but those problems can be accounted for with careful consideration.
@dangero I don’t entirely disagree with you. But that begs the question: what is the smallest atomic screen reader core? No braille support, obviously. No synthesizer built in, of course. MSAA and aria and all the other accessibility APIs should be addons. Uh…what’s left? Soon you just end up with an addon manager that makes so few assumptions it does nothing at all. Sounds like just telling someone to download Python and build a screen reader from pip packages. My point is it’s possible to go too far in either direction. But where the line is requires intentionality. It should be designed and decided, not just evolved.
@fastfinge I wish so much of this wasn't on-point.
* I don't have enough of an understanding of the addon store stuff to be informed, but pulling Remote into core seemed a lot of work for relatively little gain to me. * the on-device description stuff was mad, given the profusion of other addons already out there and its crapness when they did work on it, * and the lack of a bridge from 64 bit felt like a kick in the teeth. as you say: the move was needed, but the support for developers fell short.
I love NVDA and will champion it, but I do wonder about the direction and decisionmaking sometimes.
@cachondo@fastfinge None of it is on point, and if he'd bothered taking the time to actually ask us any of the questions up front, we would happily have cleared up any confusion.
@NVAccess@cachondo So anyone with any questions at all should ask directly and in private? That doesn’t scale. The fact you can’t point anyone to the public places where these answers can be found is even worse.
@fastfinge@cachondo The fact that we have been MORE open & willing to discussin things on here than basically any other company (please, point me to a thread in which ANY company got more involved on ANY topic? I'm waiting....) All we asked was that where you believe something is a security vulnerability, you disclose that privately in the first instance. That's all, nothing more sinister. Otherwise, I really don't think you can make any kind of argument that we don't discuss things publically.
@NVAccess@cachondo I think you are confused between discussion and argument. But if these things were discussed publicly, searching GitHub and groups.io didn’t turn them up. If they had, I’d have no questions and nothing to write.
@fastfinge@cachondo IN your article, you yourself open with "But I'm probably missing context, so I'll just have to trust that NVAccess knows things I don't." - hence, why would you not reach out to us first to find out WHY we did things a certain way?
@fastfinge No one said that. It's an open source project, discussion happens on the issue tracker and/or mailing list. Or you can ask them here. You know this. Should NVDA have a full time public relations person to handle all concerns? Who pays for that? What priorities suffer?
Your piece seems somewhat premised on the idea that you must trust NVAccess in an informational vacuum. I don't think that's true at all. You could just... ask them why they did XYZ. If that answer isn't satisfactory, okay, the discussion has moved forward.
@prism@fastfinge@cachondo Thank you. And yes, I have spent the last hour or so on this thread, and I haven't even got to half the article yet. So this HAS cost the organisation my time in doing this, when I suspect most of it could have been resolved just by asking a couple of questions first. And just to be clear, asking questions is perfectly fine. It's where they are done as public accusations of poor behaviour without first having obtained the facts that it gets frustrating
@NVAccess@prism@cachondo And that can only happen when the facts aren’t already public. For an open source foundation, that is a problem in and of itself. However, I apologize for wasting your time. In future, I’ll be sure to waste just as much of your time asking questions that should have had public answers when the pull requests were first opened.
@fastfinge@cachondo@prism But the decisions about <insert feature here> were made <gestures vaguely>. At this point, I do appreciate the passion you have, and I am honestly trying to work with you.... but I don't even know what you are mad about anymore?
@NVAccess@cachondo@prism I’m not mad at all. I’m concerned. Deeply. But that’s far from anger. And I also find it strange that you seem to think my entire purpose is to waste as much developer time as possible, and would be gleeful the more of your time I can manage to take up. I’m so baffled by that assumption thatI’m starting to wonder if your mental model of me as a person is just so far off that mutual communication or understanding is even possible.
@fastfinge@cachondo@prism Not at all, I was just concerned that you spent a LOT of time writing up incorrect assumptions which could easily have been corrected by either asking, or more fully reading discussions on github etc.
Ok just to satisfy you that it isn't only my time you've taken up this morning, but our other staff who also tried to work through your post, here is a comment from one of our developers:
@NVAccess@cachondo@prism I did find some of these. But a lot of them seem to be discussions of how to do something that has already been decided would be done. Not of the what to do or why to do it. And those discussions are the majority of my concern. However, I could be mistaken, and I will certainly read the links more closely.
* NVDA Magnifier available for early testing and feedback: This presents a fait accompli. It doesn't answer questions like "Why did NV Access decide to do this? Why now? Why part of NVDA and not a separate app?" Yes, I realize someone else is doing the initial work. But NV Access still needs to review it, merge it, maintain it, and so on. Just because someone does a thing doesn't mean it's in the project scope. I've refused fully formed pull requests for being out of scope. I'm sure NV Access has, too.
* AI Image descriptions progress: once again, discussion of a thing that's already happening. Not a discussion of why it's happening, or why it was done as part of core and not an addon, and no record of the reasoning and discussion behind the decision. This answers none of the questions I asked.
* Add-on store discussion: this, and the pr linked from it, get way closer to the sort of thing I'm looking for, and the sort of thing I saw all the time from NVAccess in the 2010's and early 2020's, but see much less of now. We get some insight into the thinking. Though we still don't get insight into why NVDA wanted to control the source of addons, and not leave it to the Spanish community, or discussion of the proes and cons of changing the review process for addon developers and how that decision was achieved.
* [Project] Convert NVDA to 64 bit #16304: And right here, we see the user story "Create a 32bit backwards compatible API for synth drivers and braille displays". With a five day final estimate. What happened here? Is this still happening? I did try to find out before I wrote anything at all. It remained unclear. So I'm still in a state where NV Access said a thing was going to happen, the thing did not happen, and I can't tell why or if it will happen later or never.
Samuel is a confused user who wrote what reads like a frustrated takedown piece, having hit a straw that broke the camel’s back moment in perceived lack of transparency.
NVAcess doesn’t have a public relations person, but its account that relates to the public is doing that job in a defensive stance.
You guys should kiss and make up.
You’re also kind of both right. Let’s look at the magnifier, since I consider myself an expert user of Windows Magnifier and ZoomIt:
There was no back room decision, it’s all very transparent. Here’s the GitHub issue where it was discussed:
A low vision user reported that Windows Magnifier was not following the NVDA virtual cursor.
My instant thought? No big deal, Magnifier can already follow keyboard focus, just have an option to move to mouse to the virtual cursor all the time and leverage the existing tool.
There was a discussion on the Windows Magnifier to Narrator private APIs and then the decision was make to add a magnifier solution to NVDA.
About a year later an add-on author said they’d addressed this issue by moving the mouse cursor and only had a pending problem with tabbing. They were advised the team was already working on a magnifier, but that they could open a PR for this issue.
The issue was ultimately closed by the PR that introduced the magnifier implementation.
This was discussed, decided and implemented completely in the open, and prioritized in a very surprising way.
“I can’t keep my pants up with this belt.” “We’ll make you a new pair of pants.” “I have this hole punch I used to tighten my belt.” “We’re already making the new pants.”
There are valid criticisms to make here, but they had their time and place: that issue.
I know a lot of people have accessibility and other issues with GitHub, but that is where this FOSS project is developed and that’s where enthusiastic community members should contribute. I also know there have been discussions about how to make that process more approachable for more people. That’s good, keep doing that.
Just my two cents. I hope this can put things into perspective for you guys and turn this to a more productive direction.
@prism@cachondo@NVAccess It’s not based on that at all. It’s based on the fact that when I search the GitHub and mailing lists, as far as I can tell these discussions don’t exist.
@prism@cachondo@NVAccess Seems a bit late to discuss decisions that were already made…somewhere…by someone. Compare to the Linux kernel mailing list. If I want to know what was decided, who decided it, why they decided it, when and where, all discussion is right there. NVDA also operated this way up until the last couple years. When Michael or Jamie decided anything, the reasoning was all in public. Even if I didn’t like it, the chain of thought that got them there was fully visible.
@fastfinge@cachondo@prism As Drew suggested, what do you want to know? I'm only halfway through your article and most of it is "I don't like this feature, it shouldn't have taken developer time" when, if you'd asked, we could have told you that things like Remote Access, Image Description, Magnifier, etc you complain about - were all done by others and only overseen by us
@NVAccess@cachondo@prism If you have understood that to be my primary complaint, I must have written it extremely poorly. Because developer time was never even mentioned once. My complaint is that things seem to be going into NVDA without openly accessible discussion or reasoning about the trade offs. So: Why is NVDA scanning store addons with virustotal? What threat does NV Access believe this prevents, given the overall addon security landscape? What does NVAccess believe is the purpose of addons, and when should an addon be in core vs. Not? Are there types of addons that NVDA does not believe are suitable, and should just be apps on their own? What qualifies a feature for an addon vs. Being part of NVDA? How are decisions made at NV Access, now that they aren’t as frequently discussed on the GitHub or the mailing list? How should external stakeholders get involved in these decisions? Speaking of those decisions: what is the current thinking RE: the 32-bit compatibility layer? Has this been canceled as it’s no longer needed? What is the current thinking on the secure addon API? Are we talking about extremely restricted functionality, or code signing, or manual approval of secure addons, or all three? Where can we see, developers work opt planning (if any) being done on corporate mode? Surely there’s something other than “no news” on an issue tracker or mailing list somewhere. I’m avoiding “Why did you do X last year” style questions, as re-litigation of things already done is utterly pointless. But these are the current questions that I am most concerned about.
While some of your points are valid, I don't think any of NVAccess's decisions cause distrust. As an add-on dev, I strongly support the idea of moving critical features into NVDA's core, and putting core infra under NVAccess's umbrella to improve their quality and make them sustainable and enterprise ready to help the adoption. @fastfinge @NVAccess
