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