Re: accessible_output2 Error on Mac (Python3.7.6)
@13
The NVDA DLL isn't my problem: it's the things using it. I don't particularly want to have to bundle more LGPL things as separate DLLS, and MIT and BSD licenses require you to have a whole thing in place to make sure that the license files get copied into the distribution. Not to mention that in Python, being LGPL means not being able to prevent reverse engineering (though just binding a C library doesn't infect). Unfortunately reading code under license x usually makes the result also license x unless you're really really careful. But to me there is high value in having stuff under the unlicense or in public domain, since we're talking about games and no one wants to track down all 500 (literally 500) license files that got pulled in to their project. Does anyone care? Probably not, most people here are (whether they like it or not) teenagers making games for teenagers, and no one is going to get mad that you didn't "include a copy of this statement with every substantial portion of the software" or whatever. But nonetheless.
I'm not against credit, I just don't have the resources to track things to the required degree. Library a brings in b and c which brings in d, e, and f under who knows what licenses...
The live region approach doesn't give up anything as long as all screen readers support it, and as far as I know they do (including Narrator). You just have to have a window handle you have enough control over to implement the UIA and/or NSAccessibility interfaces on and the patience to actually do it. You'll get politeness levels, so you even have notification priority. Only things you don't have are a separate braille stream and the ability to stop speech, but i've never seen a game use either of those.
My ideal game engine stuff would be built around accessible GUI widgets anyway, simply because there's just so many patterns that we reimplement when we decide that the thing to do is basically write a game-specific screen reader, so to that end I'd probably already have the window handle. But on the whole it is almost certainly much easier to include the NVDA DLL, call the Jaws COM interface, forget about Narrator, and do whatever for Mac. Plus since I haven't done the live region thing, merely worked out the pieces for it, I can't guarantee that it works.
On Windows you can override the window callback and inject into a window that already exists. I don't know if an equivalent works for mac, and I don't remember the Windows function offhand. But you respond to WM_GETOBJECT and pass all other messages through and I'm 99% sure that's good enough to get a UIA implementation of your own in. Not a great idea on anything but the thing that just grabs keystrokes because you'd have to forward everything else to the underlying control, but it'll get you enough to build a UIA tree and then in that UIA tree you set up a live region and you're off to the races. In theory. What everyone forgets is that all the stuff that exists in HTML is officially documented; if you were masochistic enough you could implement an entire browser-like control without any visual components on the screen whatsoever, just by lying to the accessibility APIs.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
