Before you use this in your next important application, please read the comment on accessibility that I posted the other day on the LCUI thread: https://news.ycombinator.com/item?id=16329640
These accessibility APIs expose a tree of UI objects, which the client (e.g. screen reader) can freely navigate and query. This basically assumes that there's a tree of UI objects in memory, which is the case for all mainstream toolkits as far as I know. But that's not the case for an immediate-mode toolkit. At least with Nuklear, the content and state of the UI (e.g. the label and current checked state of a checkbox) aren't stored anywhere in the toolkit's data structures. So I guess applications would have to play a very active role in implementing accessibility APIs, much more than they would with, say, Qt or even Win32.
This is also the reason why they are a pain in the butt to use, at least from the perspective of an IMGUI advocate. Those people usually have a game development background, so they're used writing bespoke solutions for everything.
Statelessness is a strength but also a big weakness, I doubt IMGUI will ever catch on its pure form. However, tools like React provide a fairly similar experience and they do produce object trees usable for screen readers. The missing piece here is something like a lightweight DOM for C/C++ projects.
Accessibility for games is definitely a much lower priority than accessibility for applications that are used in business, education, and everyday communication/social networking. Still, a blind person can feel excluded if their friends are playing a game that they can't play. Sometimes a given game can't be made accessible without changing the whole game mechanic. But that's not always the case. So, something to consider.
Again, thanks for reminding everybody. People need to think about it. Your advice could be toned down a bit to “please think about your audience, if you expect people with disabilities to be part of it think twice when making your own UI toolkit, or at least factor in the costs to build in accessibility features.”
In my ideal world, all user interfaces would run on the user's main portable computer (currently a smartphone), controlling devices remotely over Bluetooth, NFC, or the like. Embedded UIs would then be a thing of the past, and accessibility would simply be a matter of following the recommended practices for mainstream general-purpose platforms.
If this application is important to people in general, it wouldn't stop being important just because you happen to be blind or otherwise disabled. If everyone uses a particular walled-garden service for some daily task, blind people need to use it too, just the same as everyone else.
I was talking about app developers that build applications for jobs that require sight because of the nature of the job. Say a medical diagnostic application or airplane (simulator). You have to develop for the color blind, but for the completely blind, not so much. When selecting an UI toolkit I do not have to put that requirement up top.
For all the others, I wonder if a command line interface wouldn't just be better—sometimes not just for the blind.
Can you explain in more detail? As a person ignorant of these types of issues, I'm having a hard time understanding the connection between the lack of accessibility in an app to the firing of a blind employee.
Here's what happened as I remember it. The blind employee, Darrell, was providing technical support for a client company on behalf of his employer. At some point after he had taken on this role, the client added a requirement that anyone who worked with them had to use the Seibel CRM system in "high interactivity" mode. If I recall correctly from talking to Darrell, the high interactivity version of Seibel at this time (2006) used the Microsoft JVM. That, combined with the fact that the app implemented some custom controls with no regard for accessibility, made it completely unusable to him. So his employer laid him off. Luckily for him, they rehired him shortly after that, but only because they found a whole new role for him. One can question whether the real problem was the app developer, the client, or the employer. But the inaccessibility of the app was a critical factor.
I’m the last to say blind people are an afterthought which is why I thanked the original commenter for his reminder. I merely want to bring some nuance that there are always exceptions.
But we have to deal with reality here. Some tasks simply require normal sight. Believe me, as a legally blind person myself, I wish I could drive, but I understand why I can't and accept it. The same applies for some software applications. So all I can ask is that developers pay attention to accessibility unless there's some reason why it just won't work for their application. I think that's what your interlocutor is getting at as well.
However, I must admit that the incidents where UC Berkeley and other universities removed public access to many thousands of hours of videos of online undergraduate lectures severely reduced the extent of my sympathy for accessibility advocates.
It sounds like a no-brainer to be sympathetic to the needs of disabled minorities, but in fact I would suggest that if the community of accessibility advocates wants to be successful in their aims, then they need to absolutely avoid being associated with the intellectual vandalism we saw at UC Berkeley and elsewhere.
I'm sorry but I disagree strongly with your blind friend. E.g.
> this continuing trope of "OMG I didn't realize we needed to make our content accessible! Woe, woe are we!" passed through the realm of disingenuous and into that of pure bullshit a long, long time ago.
They are just videos of a lecture. They can be put on the internet.
EDIT: That sounds like I don't understand his point. I think I do: we've had decades to get used to the idea that content should/must be accessible, and of all institutions, a large public university should certainly be doing that now, in 2017.
However, I just can't make myself accept it. They are just videos of a lecture. They can be put on the internet. Certainly they would be better if accessible, but once up it is vandalism to take them down.
Now if someone can make technology to make that accessible, post-hoc, awesome. And if someone can make it easy for the content to be born accessible, even better! But I do not agree with making accessibility required.
And not just accessibility for blind people, of course. And here I have to be honest and admit that I haven't lived up to this ideal myself. Several months ago, I gave a presentation to a local Meetup group for software developers on making software accessible to blind people. It's on YouTube. But I haven't yet had it captioned so a deaf person can benefit from it. Nobody's coming after me with a lawsuit in hand. But now that I've thought of this, I should get that video captioned.
Or maybe the presentation or lecture itself is an archaic way to share information. You can see it in the word "lecture". It comes from reading, as in reading out loud. But the people who attend today's lectures can read for themselves. Maybe the best way for content to be born accessible is just to stick to electronic text, that everyone can read in their own way and at their own pace.
I'll argue that it's stupid that the law requires Berkeley to make its content accessible. If accessibility is something society has determined is worthwhile (I think we can all agree that it is), then it should be funded by society. Unfunded mandates are no way to run society.
How about writing a command line version of the program? Wouldn't that be much more accessible? I'm not even thinking ncurses, I'm thinking about a REPL, or even non-interactive like grep or awk.
I suspected as much, which is why I was thinking purely REPL/batch stuff. On the REPL end, I was thinking programming languages (Python, Lua, Lisp, OCaml…), and stuff like gdb. On the batch end, I was thinking utilities like grep or awk, compilers, or ImageMagick. In other words, stuff that would work well with a printer.
I personally have a concrete use case in mind: file encryption, and password manager. I intend to write a first version for the command line, because it will be smaller and easier to write. Then I may do GUI versions. I was wondering to what extent the accessibility of the GUI version even matters, considering how simple the command line version would be.