That would be even worse than the current state of things.
Accessibility services are necessarily kernel services, since they tie deeply into considerations of what the OS should/shouldn’t allow the user to do at any point.
Giving the login application its own copy of those services, would mean giving the login application (⇒ applications in general) the ability to tie as deeply into the OS as the accessibility services themselves do. Avoiding that is the whole reason accessibility was made an OS-level feature in the first place!
> Giving the login application its own copy of these services...
It’s much easier to have a lock/login screen that ties closely with the rest if the OS, but that’s not an actual requirement. As an extreme example Windows could split things so you have the login screen and the rest of windows as effectively two completely different VM’s that get swapped between.
I am not saying that’s a good idea, but Microsoft is building the OS from the ground up they have a lot of options.
IIRC, in this case it's the kernel accessibility API that's spawning these client processes from kernel-space, due to events the kernel is observing directly, rather than events being reported to the kernel from a userspace process — which is precisely how these accessibility helper UX processes get to be privileged in a way that regular userland processes aren't.
Accessibility services are necessarily kernel services, since they tie deeply into considerations of what the OS should/shouldn’t allow the user to do at any point.
Giving the login application its own copy of those services, would mean giving the login application (⇒ applications in general) the ability to tie as deeply into the OS as the accessibility services themselves do. Avoiding that is the whole reason accessibility was made an OS-level feature in the first place!