Plausible, but still an awful idea. Anyway, by the time you have something that pwned the box enough to pretend to be a screen reader to Firefox you kinda have bigger problems.

Sure, of course the tradeoff is slightly better performance for most people, 0 performance for me. I wouldn't complain so much if they had set it on the default profile they install, but doing it through group policy means a user can't edit it.

It is possible, but my point stands: if someone has local control of the box enough to present to Firefox as an accessibility provider, the box is effectively pwned in every way that matters. If you can launch an a11y provider you can keylog, or take screenshots, etc.

Correct, it was updated to 115, and yes, it's an ESR release. The previous one was absolutely ancient, I want to say 68? Something like that.

Yes, it's kind of bullshit that it's allowed to make the product inaccessible as a policy matter. Best of luck.

What does that option actually do? As in, what is the use case for disallowing accessibility?

1. There is a theoretical security factor in that there can be clients other than assistive technology products that use accessibility APIs to gather information for purposes other than accessibility. It's no worse than something taking screen shots and running them through OCR or the like, of course, but I guess the data is more readily usable. But if you've got such a client running on the system, it can already do far worse things.
2. Building and maintaining the accessibility tree means extra work for the system, so that means there is at least some unavoidable performance impact. However, that only occurs if an accessibility client is actually querying the browser. Some non-AT Windows features do use the accessibility tree - e.g. suggested actions, snap layouts - but those features just aren't going to work properly if accessibility is disabled anyway.
IMO, neither of these factors at all justify the ability to disable this in group policy. I'm also a little frustrated with folks on Reddit, etc. suggesting disabling accessibility as a first course of action when performance problems are encountered, as it robs us of valuable diagnostic information from those users.
@modulux

for security, if it is a big issue, could Firefox setup a whitelist of known accessibility programs & processes to auto allow? The same list could also work for performance, though I guess it might be annoying for less well known accessibility programs & how do you vet or add them? I remember Android had a similar issue at one point, but can't recall what ended up happening there

I don't believe it is actually a big issue, but a few folks make a big issue out of it anyway. As you say, it's risky because we might block a legitimate use case. Also, it's surprisingly difficult to reliably detect accessibility clients. We do have code for it and we do block some clients, but I wouldn't want to rely on it for an "allow list", where the consequences of failure are legitimate clients getting blocked. @modulux

Yep that was the most obvious (note not necessarily best, just first) idea.