Technical follow-up: It seems to me that implementing today's platform accessibility APIs (e.g. UI Automation for Windows, AT-SPI for Unix) would be difficult if not impractical for an immediate-mode toolkit like this one.

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 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.

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.

Your note is good in general, but for this particular case, note this is an immediate mode GUI library. I.e. the kind of stuff that's primarily used in videogames. A typical game (or supporting tool) where this is included would already be not accessible (imagine playing e.g. an RTS with a screen reader).

Point taken. Some games, though, could be accessible if not for the way the UI was implemented. For example, repackaged text adventures. I downloaded the Lost Treasures of Infocom app for iOS, and it was completely useless with VoiceOver. Presumably because the dev at Activision who was working on this packaging used the same kind of UI toolkit that they always use for games. The same goes for turn-based strategy games, if it's feasible to provide text for all the graphics.

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.

I agree. It's good that you bring this up, and also great you provided some extra context about why you're doing this in another comment.

Accessibility is always important to mention, which is why we should thank you for reminding us. In return, you have to understand that not every next important application will be used by blind people or people with disabilities, and as of such there is still room for people to develop new UI toolkits if they so please.

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.”

Thanks for your feedback. I do try to control the tone of my comments on this subject, because I get emotional about it, but I know a vitriolic comment isn't helpful. Still, I find it hard to moderate the scope of my advice. Several years ago, a blind acquaintance of mine briefly lost his job because some developer didn't pay enough attention to accessibility in an application that he was required to use. His employer re-hired him shortly afterward, because they found another role for him. But in the interim, he went through all the feelings associated with losing one's job, and he was lucky to regain employment so soon. I don't ever want anyone to go through that again because some developer used an inaccessible GUI toolkit, even if that toolkit was meant only for games. That's why I'm as vocal as I am here.

> Several years ago, a blind acquaintance of mine briefly lost his job because some developer didn't pay enough attention to accessibility in an application that he was required to use

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.

Sure. We're getting off on a tangent now, but I guess that's why people can collapse subthreads.

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.

That makes a lot of sense. Sucks to go through such a situation. Cheers for trying to make a better world.

> not every next important application will be used by blind people or people with disabilities

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.

If you develop for an audience where you do not know every of your end users, i.e for the generic public, i would argue you can never say it will not be used by blind people (and hence have to develop for it).

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.

That's reasonable, as long as a developer, once familiar with a toolkit like this one, doesn't go on to use it for applications with a less restricted audience.

There are a couple domains for which I'm pretty sure sight is required. Photoshop for instance. Is there any way this program could be made accessible?

For all the others, I wonder if a command line interface wouldn't just be better—sometimes not just for the blind.

A decent UI toolkit has accessibility built in, so using such toolkit and adhering to the platforms design language takes you quite far in not obstructing disabled people. Something like an interactive website, for example, if one follows good practices, is effortlesly disabled-friendly.

A good UI toolkit with built-in accessibility helps, but in non-trivial applications, it still takes thought to make sure you use the toolkit correctly. In my experience, there are myriad ways to accidentally mess up accessibility. So I wouldn't use words like "effortless".

People with disabilities don’t need random developers determining a priori whether or not they’ll be able to use the same software as everyone else. People with disabilities aren’t an afterthought; they’re not a bonus; it’s a requirement to produce software that everyone can use — not just people like you. If it were more work to produce software for people of another race than yourself, would you be making the same argument?

Did you read my comment below? I made the comment with application developers in mind that develop applications for job types that require sight as a first job requirement (pilots, doctors, ...).

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.

And to reiterate, I agree with that nuance and will do my best to apply it to future comments.

I’m disagreeing with that nuance. I’m saying that blind people should be able to enjoy the same things that sighted people can, rather than developers deciding for them whether or not blind people are in the target market.

Your strident advocacy is admirable, and that's why I upvoted your first comment.

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.

Fair enough. I think we’re pretty close together on that.

Additional advice: "don't use this toolkit if you ever want to sell your product to government".

Which is interesting because I use a dialysis machine and these are essentially sold to the government instead of the patient yet they all use a custom GUI interface like this one. Far as I can tell there is no accessibility features.

That's a difficult case, because it's a dedicated device and not a general-purpose computer. Adding a screen reader to such a device could be costly. Of course, these days, even a lot of "embedded" projects use Linux, some embedded flavor of Windows (previously CE, now Windows IoT Core), or even Android. Still, the device would need audio output. And to really cover the bases, for deaf-blind people, it would need to connect to a braille device via USB or Bluetooth.

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.

TBH this looks mainly oriented towards games where usually the only UI accessibility you have to be concerned about is for people with color blindness.

It's the only accessibility developers usually ARE concerned about, but in many games, it would be possible to do much better. Uncharted 4, for instance, is highly accessible: https://dagersystem.com/all-review-list/disability-review-un...

I think your comments here and in the other thread are thoughtful and well-intentioned and are in general the right comments to make.

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.

What Berkeley did with its lectures is not the fault of accessibility advocates. I'll just point you to this comment from a blind friend: https://news.ycombinator.com/item?id=14580342

I am not sure what you mean by "fault" but it was certainly the result of accessibility advocacy.

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.

I think I understand why the outcome in this case frustrates you. Taking down the videos didn't do anyone any good, except that it was the easiest way out for Berkeley. Now, nobody has access to that information. So, one might argue that it's stupid that Berkeley was required by law to remove inaccessible content. But if that requirement wasn't there, the law would have no teeth, and other content wouldn't be made accessible. What we all wanted, of course, was for Berkeley to make the lectures accessible, not remove them. The fact that Berkeley removed them is Berkeley's fault, not ours. Your problem should be with Berkeley, not with us.

> So, one might argue that it's stupid that Berkeley was required by law to remove inaccessible content. But if that requirement wasn't there, the law would have no teeth, and other content wouldn't be made accessible.

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.

I'm just going to be honest and admit that my instinct is that demanding accessibility is too high a barrier. I want to live in a world where a lecturer is about to start a lecture and someone in the class says "hey can I record this it would be cool for others to see" and the lecturer says "sure!" and the simple phone-captured video goes up on the internet for ever.

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.

I understand your opinion, but I think I must still disagree with it. I do think accessibility should be required, unless it's just not possible in some situation. And content should be, as you said, born accessible.

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.

Let's say I'm implementing an application blind users should be able to use (not an FPS game or drawing program). Aren't GUIs a pain in the butt even when properly implemented with the right accessibility hooks?

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.

Blind programmers and sysadmins sometimes prefer command-line tools. But most blind people are now thoroughly accustomed to GUIs. An accessible GUI can be very usable. IMO, it's much better than using a screen reader with a screen-oriented terminal application (ncurses or the like). If you're skeptical, I can put together a little demo of one or two use cases on Windows and/or the iPhone.

> IMO, it's much better than using a screen reader with a screen-oriented terminal application (ncurses or the like).

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.