One clearly defined starting point is exposing any custom controls to accessibility APIs that are used to enumerate and interact (simulated mouse actions, reading the text, etc) with controls on the screen. Both scripting tools and screen readers make use of these. Built-in controls already have the enumeration and interaction feature and don't need additional code, but custom controls may not have that.

In the MicroUI example here, there are buttons and text labels and other kinds of controls, but no ability for an outside process to enumerate or interact with the controls. Any program will just set a single giant window with no text and no controls inside. Accessibility software can still hook text output APIs, but not if it also uses custom font rendering.

Anyway, the Windows accessibility API is just implementing a few COM objects, and COM (other than the specific ABI used for storing the vtable and function call convention) is not necessarily specific to Win32.

This is one of the reasons why web technology is so popular and persistent. You get almost all of that for free as long as you use semantic HTML.

OK, if "toy project" isn't the right word, then perhaps, "unethical" or "exclusionary" would be better words to use.

I judge software harshly that could be useful to folks with accessibility needs that don't try to address it (within bounds of their resources and capabilities, obviously lots of OSS just doesn't have the ability to deliver an accessible experience for tiny little throwaway apps). I definitely choose technologies to use based on whether they can be accessible with a little extra effort on my part. I'm not necessarily good at it, it's a complicated topic, but when I get bug reports about an accessibility issue I tend to drop everything else and try to fix it.

I guess a lot of folks consider games exclusively for folks without those accessibility needs, so maybe that's why something like Dear ImGui can live for years in thousands of projects without anyone complaining about accessibility. But, I wouldn't consider it for anything that isn't specifically about graphics and I don't think anyone else should either. (No one has to listen to me, but I think less of them.)

You've cherry picked a very specific example that is designed to run in 3d engines. For anything rendering at standard OS api level level (the vast majority libs), accessibility is fine as evaluation criteria.

> sad that the world is so hung up on unicode

It is sad that the world is hung up on enabling 2/3rds of the world population to read and write text! If only the entire world catered to America. Nobody should ever speak anything other than English, honestly.

Being accessible to the intended users always matters. If you think it doesn't, that probably means it's currently accessible to those users (or that those who are it is inaccessible to have filtered themselves out, and are no longer users).

For example - in your debug UI, colorblind-friendly colors don't matter, until you hire your twelfth member of the team, who struggles to tell red and green apart.

I can’t say how it compares to others, but Godot added screen reader support in 4.5 a year or so ago.

The point of a UI library is to interface with users. If it totally fails to interface with a subset of users then it is obviously deficient to some degree. It is callous and foolish to dismiss offhand users who rely on assistive technologies. You probably have a poor idea of who they are and how many people we’re talking about. You never know when you or someone you care about will become one of them, even temporarily. You never know how far your software will reach when you write it.

> Any project that uses Dear Imgui for end-user applications has already made a bad design choice.

Note that any project using Dear ImGui will presumably have read the README for it, the second paragraph of which starts:

> Dear ImGui is designed to enable fast iterations and to empower programmers to create content creation tools and visualization / debug tools (as opposed to UI for the average end-user).

It's supposed to be a _tiny_ library. Naturally its capabilities will tend towards being minimal. I don't expect decent RTL language support, for example, although it's quite important if those are the languages where you live.

As for linking to something written in Rust with bindings etc. - that is the opposite of tiny when you consider the dependencies, and it would not be portable to weaker or older systems.