Accessibility support

[ethindp]

I'm curious aboutwhether accessibility has been considered for use with assistive technology. I know that this library supports win32/GTK and such, but for integration with libraries like SDL2/SFML/Magnum/... a large number of events need to be handled. If this hasn't yet been considered (or if the library uses custom widgets and doesn't use those provided by the operating system), there are two options, one of which is considerably more complex than the other, but which has much greater payoffs in the long run:

1. Allow clients to handle all of this
2. Incorporate the accessibility APIs for each platform for all the different widgets that Elements supports.

The first option puts all of the burden on the user. That's probably not a good thing since that means the user has to learn a bunch of things that they shouldn't care about (and it's easy to screw up). The second option is the one that would probably be preferable, if only because it leaves the complexities where they ought to be and allows the client API to remain clean. For Windows, you would probably want to incorporate UIA. There are a couple others (MSAA and IAccessible2), but incorporating all of these is far too much work and I'm pretty sure most UI toolkits don't bother with them anymore. I have no idea how MacOS'saccessibility API works (Apple has been very tight-lipped about things like this), so a hack might be necessary (or we might just want to ignore MacOS/iOS entirely). (That'll be sad for any MacOS users, but the blame is squarely at Apples feet.) Linux/BSD have ATK and AT-SPI (though the Linux accessibility story is a bit of a mess, and I'm not sure which API to use, or whether you have to use both).

I'd contribute but I don't know much about either UIA or ATK/AT-SPI from the perspective of a UI toolkit designer. If the host parts of the library just use native widgets, though, then this library can definitely be a big contender alongside the other toolkits like WxWidgets. I'll look into UIA, though I think that the only problem might be interacting with COM (unless we could use it via C++/WinRT?).

[ethindp]

Any update or anything about this? (As an aside, on win32/GTK backends, are the native widgets used?)

[djowel]

Sorry about that. No, native widgets are not used. To be honest, I do not know much about this subject either. So, I am not sure how to approach this. If you are interested in investigating, that will be very welcome.

[redtide]

Might be useful for reference this JUCE document about the context, see also the links below under "Further Reading".