I think ZenPsycho is right calling out for accessibility features. It's unfortunate that most low-key UI libraries don't support them, partly because those OS API are so complex and for a non-user it is hard to understand them (much like for English users it is sometimes hard to understand what's needed for localization).
A pragmatic way to see it - and arguably it's an issue I don't have answer for - is that the sum of all desirable modern features (incl. but not limited to accessibility features) are growing the scope so complex and large it is also - very unfortunately - hindering innovation. Everyone agrees accessibility features are desirable. Yet if every experimental or hobbyist project needed to implement all accessibility features, those projects wouldn't exist. So two steps forward is costing us one step back here :(. There are _so many things_ dear imgui doesn't do at this point, it can't handle full internationalization and right-to-left text. Maybe it'll catch up. Maybe other solutions will solve this. For now as I don't have the resources to do it all myself. But the more people use and work with a given software the more likely it is to evolve and improve. I would gladly surrender to a much better product than dear imgui that implemented this while also solving the problems dear imgui aims to solve.
Until HR/regulations/compassion hits you, please don't comment please.
Got it though - these things are perceived as - meh, why would I need it - I have perfect vision, two hands, can speak, can hear, can touch, etc. And then you start realizing you maybe working with folks with disabilities, and the same products/apps that you are working with allow them to do so (like Visual Studio), so on one hand it's easy to ignore them (without even realizing so), but once you've become aware of what they are facing, and seen enough it makes you think - should I use this, because there is no native control, and usually native controls have ways to be decoded by Assistive tech (my reasons back in the days to prefer wxWidgets over Qt), or recently even if it's non-native (Qt, flutter, etc) it can feed to the assistive sdk (say on Windows) details of what's going on in the control.
It's rather important! It's not just a gimmick. It shows compassion, love, and someone might already a project doing so with "Dear IMGUI" (not aware of one), but probably internals can be exposed in some fashion.
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.
mcdevilkiller|5 years ago
ocornut|5 years ago
A pragmatic way to see it - and arguably it's an issue I don't have answer for - is that the sum of all desirable modern features (incl. but not limited to accessibility features) are growing the scope so complex and large it is also - very unfortunately - hindering innovation. Everyone agrees accessibility features are desirable. Yet if every experimental or hobbyist project needed to implement all accessibility features, those projects wouldn't exist. So two steps forward is costing us one step back here :(. There are _so many things_ dear imgui doesn't do at this point, it can't handle full internationalization and right-to-left text. Maybe it'll catch up. Maybe other solutions will solve this. For now as I don't have the resources to do it all myself. But the more people use and work with a given software the more likely it is to evolve and improve. I would gladly surrender to a much better product than dear imgui that implemented this while also solving the problems dear imgui aims to solve.
malkia|5 years ago
Got it though - these things are perceived as - meh, why would I need it - I have perfect vision, two hands, can speak, can hear, can touch, etc. And then you start realizing you maybe working with folks with disabilities, and the same products/apps that you are working with allow them to do so (like Visual Studio), so on one hand it's easy to ignore them (without even realizing so), but once you've become aware of what they are facing, and seen enough it makes you think - should I use this, because there is no native control, and usually native controls have ways to be decoded by Assistive tech (my reasons back in the days to prefer wxWidgets over Qt), or recently even if it's non-native (Qt, flutter, etc) it can feed to the assistive sdk (say on Windows) details of what's going on in the control.
It's rather important! It's not just a gimmick. It shows compassion, love, and someone might already a project doing so with "Dear IMGUI" (not aware of one), but probably internals can be exposed in some fashion.
minerjoe|5 years ago
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.