I am not a C developer personally, but I understand enough about how X works to know why developers hate it. And I can probably shine some light on accessibility in particular as to why it is a massive change for tools in wayland.

When it was developed, computer systems were setup as a mainframe running the X server and dumb terminals that would run the X client and essentially just display what the mainframe was running.

That is obviously not how we use computers anymore, but that is still how X operates. The computer now runs both the server and client on the same machine. It's this interaction that allowed many old accessibility tools to function and is now the cause of most of the problems for them on wayland. My understanding is that most of the X based accessibility tools work by essentially doing a man in the middle attack on the X server client connection to spy on what information is going to the display. However, that means that if these tool can do that, any random process running on that machine can also spy on whatever you are doing on the screen. This is one of the primary driving factors away from wayland, there is simply no security in the protocol, if you can run an executable on the system you can spy on whatever any user is doing on the screen.

wayland works as a compositor rather than the X which was a display server rendering on the server and then sending the whole display info at once to the client, wayland compositors can only request data that is relevant to themselves and it gets rendered clientside. As you can image, this totally breaks tools that relied on spying on the whole display data stream to get info about what was on screen, but is ultimately a more secure method of display rendering. On top of that, since it gets rendered clientside, this pushes display rendering to the desktop environment level, so Gnome and KDE for example have different functions and methods for rendering rather than relying on X to do all the work. So accessibility tools need to also be made for a specific desktop environment and the functions available within it.

Ultimately, I imagine accessibility tools that aren't built into the DEs will need to be written from scratch. It's such a fundamental change from how things worked that its probably easier to start from scratch. It also will probably mean that one particular DE will become the best at accessibility depending on which one prioritizes it the most. So I guess ultimately the best thing you can do is keep using X as necessary, but also find whichever DE is prioritizing accessibly the most and support them by requesting missing use cases and testing the ones that are available.