Do you think it would make sense to implement bridges from platform accessibility APIs that push updates to AccessKit? For example, this could make Wine accessible if you run a UIA or MSAA client inside Wine that pushes tree updates to AccessKit over some kind of socket, which Orca or Odilia could interpret and let you navigate and read. Or you could do the same thing with WSL2, having an ATSPI client that forwards updates to AccessKit which JAWS or NVDA or Narrator could interpret. Maybe you could even do this for virtual machines, to improve performance and responsiveness, and so you can use your favorite screen reader with any OS you want. I think ChromeOS makes Android applications accessible with this kind of bridge, because when you use Android apps on ChromeOS you're still using ChromeVox with the same commands and speech settings and navigation works the exact same way, even though you're using an Android VM, not a thin emulation layer like Wine.

@emassey0135 The difficult part here is efficiently gathering information from the current pull-based accessibility APIs (UIA, AT-SPI). In the specific case of Wine, where the UIA implementation (but not the API) could be changed, this might be more tractable. It's something I'd like to work on sometime.

@emassey0135 Then again, the most efficient way to gather information from UIA would probably require Wine to implement the UIA feature called Remote Operations which I helped implement while I was at Microsoft, and that feature is covered by a patent. Yes, I'm deliberately sabotaging my ability to just ignore the patent, by mentioning it publicly.

@emassey0135 For what it's worth, the best public overview of the UIA Remote Operations feature was probably the description of this NVDA PR by Michael Curran: github.com/nvaccess/nvda/pull/… The feature is mostly not of interest to UIA providers (toolkits), only clients (ATs).