The problem is that accessibility APIs are very limited and stagnated in every single OS (except maybe Apple).
For basic default widgets accessibility works out-of-the-box, but as soon as you want to do something more complex or do custom drawing like Dear ImGui does, you're forced to write WAY more code than anticipated.
In Windows, for example, you need significantly more code to get a11y than to draw a custom widget. If you're drawing to a framebuffer like Dear ImGui is doing, it's even worse. In some OSs have to use other APIs (like focus management) to take advantage of the a11y APIs, which is kind of "at odds" with the whole immediate-GUI paradigm.
This is amazing new for corporation-backed products like Flutter, React Native or even Qt, because it makes the barriers to entry way higher. On the other hand, open source project will lack the resources to do proper native a11y.
Asking OS vendors to have proper accessibility in their OSs is IMO the more appropriate step for accessibility advocates, rather than forcing dozens of Open Source projects to reimplement the same thing over and over.
> Asking OS vendors to have proper accessibility in their OSs is IMO the more appropriate step for accessibility advocates
What more should OS vendors do? Is there anything OS vendors could do that would actually help the state of accessibility in fringe GUI toolkits like Dear ImGui? This isn't a rhetorical question. In addition to being an outspoken accessibility advocate on threads like this one, I'm currently a developer on the Windows accessibility team at Microsoft, which owns the UI Automation API among other things, and I want to know what more we should be doing.
ratww|5 years ago
For basic default widgets accessibility works out-of-the-box, but as soon as you want to do something more complex or do custom drawing like Dear ImGui does, you're forced to write WAY more code than anticipated.
In Windows, for example, you need significantly more code to get a11y than to draw a custom widget. If you're drawing to a framebuffer like Dear ImGui is doing, it's even worse. In some OSs have to use other APIs (like focus management) to take advantage of the a11y APIs, which is kind of "at odds" with the whole immediate-GUI paradigm.
This is amazing new for corporation-backed products like Flutter, React Native or even Qt, because it makes the barriers to entry way higher. On the other hand, open source project will lack the resources to do proper native a11y.
Asking OS vendors to have proper accessibility in their OSs is IMO the more appropriate step for accessibility advocates, rather than forcing dozens of Open Source projects to reimplement the same thing over and over.
mwcampbell|5 years ago
What more should OS vendors do? Is there anything OS vendors could do that would actually help the state of accessibility in fringe GUI toolkits like Dear ImGui? This isn't a rhetorical question. In addition to being an outspoken accessibility advocate on threads like this one, I'm currently a developer on the Windows accessibility team at Microsoft, which owns the UI Automation API among other things, and I want to know what more we should be doing.