It would be smaller than Libaudioverse and all the accessibility APIs save Linux are fully, 100% documented.  The semantic meanings of all the basic controls are the same on all platforms.  It's just the facade pattern and then a bunch of testing.  It's not even a technical challenge, not really, just mind-numbingly boring and with a lot of tedium.
Basically you build a core model of accessibility for whatever you can support.  Button, combobox, checkbox, radiobutton, textrbox, slider, and maybe rich text are all doable.  You also implement the support for focusing controls that don't actually exist (this is what happens on the web, for example).  On top of that, you implement the platform specific interfaces for accessibility, which contain tons and tons of boilerplate (for Windows it's something like 300 or 400 lines).  These just read your platform-agnostic representation and return it, and sometimes raise events when the platform-agnostic version changes.
After that you write a manual documenting the best practices.  For example implement keyboard navigation and focus tracking (which does not come from the accessibility API unless you're on OSX).  And then you provide the platform-specific hooking samples.  On Windows this is "Put this code in the callback", on Mac it's "Have your root view inherit from this class or paste this chunk of code".  And that's it.  You've now made a cross-platform toolkit that can cover all the basic control types,.  If you need more than is covered, you open a ticket and we add one.  Or you implement it as more than one control and use the virtual hierarchy.  Or you map it to one of the controls that already exists.  There's a reason we don't get 50 new controls with every new OS: all the controls that people actually want already exist, and custom controls usually just do the same thing as one of them with a different look.
It's about a year of full-time work and probably fundable, once you've proven the concept.  I'm not the only one who thinks this is possible either: Matt Campbell from Serotek agrees with me that it could be done.
As for C versus C++?  yeah, it'd probably use C++ internally; nowadays, if you have to choose between the two it's best to always pick C++ in my opinion.  But if you want the library to be callable from any language but C++, you have to expose it to the external world with a C API.  There are Gui frameworks using OpenGL and only these controls in Python.  They exist in Rust.  Go.  Java.  C#.  Almost every language has OpenGL GUI frameworks, and almost every language has a fully capable C FFI.  You can wrap it behind something nicer if it's callable, but it needs to be callable first.  This is what libaudioverse does, you can make it work out very nicely with some macros or a program, or you can just take the hour or two to do it manually.  If you need C++ classes, you can later implement them on top of the C API; but if it's a library intended to be used from anything but C++, the C API needs to be the first and authoritative interface.
I don't consider this technically hard.  I consider this tedious and I'd never, ever do it for free because of the huge boredom factor.  But someone needs to, and it's on the queue of projects I want to do if I can get some money.  It's not actually different from WX at all, it's just going in the other direction (that is, instead of it calling the OS, the OS calls it).  I learn new APIs all the time for everything I do.  Adding 5 or 6 more is by no means impossible, though I will concede these are perhaps larger and less user-friendly than most.
As for the justification?  No one wants to add a few thousand lines to their GUI framework; no one tests it when they do.  This would centralize the effort.  If I did it, it would be centralized with a blind person in control.  If it existed, there is basically no doubt that people would use it; Kivy almost certainly would, for one.  In fact the reason I started thinking about this was because I was looking at doing Kivy accessibility.  The truth is, making a GUI framework accessible on all platforms takes literally exactly as much effort as writing this library; every time someone does it, they do exactly this, they just aren't separating the code into something reusable.