This comment-and-response pair has a really weird "shape".
You're offering a retort to someone who is communicating their position that you ought not do something, where the retort consists of nothing more than explaining that people are doing it. Yes, clearly. But what the person you're responding to is arguing is that you ought not do it.
Consider the following hypothetical:
Person A: Here's little advice: don't take up smoking. Smoking is bad for you.
Person B: Yet people smoke—my cousin, for example.
The point of the other comment wasn't that it isn't happening or that it's physically impossible to even try. Indeed, the fact that it's being done—or that people are attracted, at least, to trying to do it—was rather the entire premise of their "word of caution".
I wouldn't go that far. But "this lacks accessibility" isn't sufficient reason to rule something out, imo. It's better for a piece of software to exist, without accessibility accommodations, than it is for it to not exist at all.
No, there's a tradeoff. If non-accessible software outcompetes and crowds out accessible software, that degrades the ability of people who need accessible software to use their computers. It is entirely reasonable for people who think that people with disabilities should have equal access to technology to advocate against the development of software without accessibility features.
It's a bit sad that something like an iMessage client for Android gets so many people here passionate about the ethics of access to platforms, but you get downvoted pointing out that certain tools/strategies for building software can leave whole classes of people out of computing due to factors entirely out of their control.
And you get downvoted for pointing out that here in Europe you're required by law to make software accessible. (At least in theory, don't know if it's enforced at all.)
Well, here in Europe you can get sued if you provide a non-accessible software. (Games are excluded and a photo editor can of course assume that the user can see etc.)
It seemed like you were criticizing the "accessibility song and dance that happens every time a GUI library is the topic", as if you think accessibility concerns are over-blown. If that wasn't your intention, I suggest you clarify what you actually mean.
It seems this might not be the case for American English, but "song and dance" is only ever dismissive in British English. The implication is that the complaints are a needless distraction, due to the relative insignificance of the topic.
Accepting this, for the sake of argument: sounds like warnings such as jakelazaroff's are a good thing then, to make sure creators are informed enough to decide.
I agree, which ... is why jakelazaroff is warning that ImGui is meant for internal custom tools, not tools where things like accessibility is a concern.
Accessibility is only not a concern for internal custom tools if you're certain you're not going to hire anybody with a disability that requires those accessibility features. (You shouldn't be certain of this, because it means you're probably breaking the law.)
Accessibility is one (important) consideration but it's true that tools with a small, known subset of users can afford to ignore some constraints. For example, if you're a small American company, your internal tools might not need to support right-to-left languages.
I don't see any reason you couldn't hire a blind level designer, but sure, there may be some subset of "internal tools" that you can make that assumption for. But the topic wasn't "internal tools for visual artists", and a lot of workplaces have internal tools that are inappropriately and unjustifiably inaccessible.
Sure, if you put in a lot of effort you could probably make a professional app with it. You'd need to recreate a bunch of features that come for free in more "bloated" UI libraries. But you could do it! More likely, though, is that you won't and your "professional" app will just end up being bad for lack of those features.
