As usual though this statement is posted yet no real references are linked on how and what needs to be actually done to make a graphical user interface good for accessibility. Rules like have a high contrast color version for people with less eyesight. I tried to find resources about accessibility a while back to actively work towards it but couldn't really find anything official or sometimes only behind paywalls.
Not sure if commenters posting about accessibility have a disability themselves or are speaking up for people with disability. However reality is that in total it is a small percentage of users and without guidelines or having a disability yourself it is really hard to work towards. Especially at least from what I have seen in games the variety and range of disability. Without good guidelines and accessible interfaces for aiding tools. So requiring a gui library without funding to have a high level of accessibility or labeling it worthless is a somewhat cheap way of judging these libraries.
Good points overall. The reason nobody posts examples or references is because it's way too damn hard right now.
Current accessibility APIs are tightly coupled (conceptually and logically) to APIs that originated in the 80s: Win32 and Cocoa.
If you're only using native widgets it's virtually automatic to have full accessibility. But as soon as you need minimal customisation you have to interact with extremely verbose APIs. Cocoa's API is much better, but MS's Automation API is very arcane and complicated, and even MS employees acknowledge that.
On top of that, even if you're using the APIs as intended, the examples provided by Microsoft are low-quality and are not a good starting point for implementing accessibility on non-native.
Thus, only giant corporations have the resources to fully re-implement accessibility in non-native applications. Google can do it in Flutter and Chromium (Electron). Nokia for Qt. Facebook for React Native. But single developers just don't have the power to do it on their lightweight libraries.
What we need is a smaller lower-level accessibility API that gives accessibility to game engines, non-native UI toolkits, TUIs and command line apps. But I don't think there's much incentive coming from OS makers to do it.
As far as I know glfw, sdl and allegro work for OSX as well. But if that is not the case I still have demo code for Mac, iOS and tvOS. The problem is I don't have any of these platforms and the demos are from an old version. So if somebody is found to take over the porting I can release it again.
There is nothing really dependent on any of the provided demos. As long as you are able to provide an OS window, input and a way to either draw basic shapes or vertexes you are good to go.
There are two different versions. The first one uses pixel measurements like you said the other one uses a fractions of the window.
If it is something requested then it is something that can be changed quite easily either by me if the feature is requested or the user since it only requires modifying one function. Furthermore for input you only provide your input data the library does not control it and the output can be scaled if required.
Another lightweight ANSI C library is https://github.com/vurtun/zahnrad. It is platform and render backend independent, has no dependencies and is configurable.
Not sure if commenters posting about accessibility have a disability themselves or are speaking up for people with disability. However reality is that in total it is a small percentage of users and without guidelines or having a disability yourself it is really hard to work towards. Especially at least from what I have seen in games the variety and range of disability. Without good guidelines and accessible interfaces for aiding tools. So requiring a gui library without funding to have a high level of accessibility or labeling it worthless is a somewhat cheap way of judging these libraries.