"Accessibility" is an open-ended set of functionality, not a checkbox; it is never "complete", there is always room for improvement. Colorblind support (which ones)? High-Contrast mode? Adjustable text size? Screenreader integration? Localization? IME support? Keyboard navigation? Keyboard remapping? Functional entirely without a keyboard? Touch support? Pen support? Dyslexia-aiding typefaces? The list goes on and on.
One clearly defined starting point is exposing any custom controls to accessibility APIs that are used to enumerate and interact (simulated mouse actions, reading the text, etc) with controls on the screen. Both scripting tools and screen readers make use of these. Built-in controls already have the enumeration and interaction feature and don't need additional code, but custom controls may not have that.
In the MicroUI example here, there are buttons and text labels and other kinds of controls, but no ability for an outside process to enumerate or interact with the controls. Any program will just set a single giant window with no text and no controls inside. Accessibility software can still hook text output APIs, but not if it also uses custom font rendering.
Anyway, the Windows accessibility API is just implementing a few COM objects, and COM (other than the specific ABI used for storing the vtable and function call convention) is not necessarily specific to Win32.
This is one of the reasons why web technology is so popular and persistent. You get almost all of that for free as long as you use semantic HTML.
Which nobody uses