If some developer, trying to fight the rising tide of complexity, develops an app using this or a similar toolkit, for a task that doesn’t have inherent accessibility barriers, and as a result some blind person (or person with another disability) can’t do their job, I won’t care how few lines of code the toolkit required. Some problems are inherently complex, and developing a user interface that accommodates the full range of human abilities and needs is one of them. Yes, software complexity often gets out of control, but sometimes we react to that by going too far in the other direction.
P.S. Yes, I’m assuming a world of opaque, proprietary applications that people are compelled to use to make a living. In a world of free software and open protocols, I suppose this wouldn’t be such a problem.
Yes, software complexity often gets out of control, but sometimes we react to that by going too far in the other direction.
I do think there is a place for very simple software. Even if it isn’t a good idea to use it in a general setting, it still provides a great opportunity for people to learn about topics. It would be very scary to learn about compilers if the only available reference was GCC.
To be clear, I don’t think that you are advocating for the removal of projects like microui. I just want to provide an alternative view on the usefulness of the project.
libatk is not that difficult to deal with, full atk reference here. For LibreOffice, the interface is extremely small, despite how complex the LibreOffice GUI source is (For this it would probably only be a few hundred more lines – hardly a tradegy!). Also this (Accerciser) is a good tool to check just how Accessible your app is.
It is, quite frankly, amazing that I have a ‘troll’ downvote. As in, it amazes me how little people give a shit about others. As mwcampbell noted, these small toolkits are often attractive to in-house development, and small developers who do not wish to work with ‘bulk’.
I am a fan of small software, I’ve also been familiar with rxi’s stuff “before he got popular” (And knew him somewhat, a long time ago), I know and agree with the goal he intended here. However, that does not mean that this software gets a free pass for excluding users that are disabled. And if you intend to have universal accessibility, where else would you implement it? It’s either implementing it on this layer, or forcing every other downstream software package to implement it from scratch, which is clearly ludicrous.
I hesitate to write this, because I also don’t want to excuse inaccessibility. But I understand why it happens, and think it might be worth providing some explanation.
First, it’s not clear to me whether ATK can be used independently of GTK. Also, GTK 4 has stopped using ATK; now it implements AT-SPI directly. So it seems to me that ATK is deprecated.
In any case, both ATk and AT-SPI are only relevant to the tiny fraction of users who use one of the Unix-based free desktops. Implementing either of these won’t help users on Windows, Mac, the mobile platforms, or the browser (via WebAssembly).
And ATK might be one of the saner accessibility APIs to implement. While I was at Microsoft on the Windows accessibility team, I spent two of our annual Hackathons helping a non-profit group (the Quorum educational programming language project) with their implementation of the Windows UI Automation API. I saw just how badly they could screw up their UIA implementation, not due to incompetence, but just because they’re not experts in Win32, COM, and UIA itself. I eventually found out that they used some old Windows SDK samples as a starting point. Microsoft’s own sample implementations of UIA encourage practices that are bad for most modern toolkits. For example, the samples assume that each control has its own OS-level window handle. That’s fine for a sample with a single control, but not for a full toolkit. So the Quorum folks figured they should create dummy window handles for all the controls. I spent most of the first Hackathon correcting that design flaw. Unfortunately, a good UIA sample needs to either be based on a real GUI toolkit or implement one of its own. If I had stayed at Microsoft, I probably would have spent my next hackathon creating that sample. I might still do it on my own time at some point.
Another challenge is how to expose your platform accessibility implementation(s) if you use a cross-platform abstraction layer like SDL or GLFW to handle input and windowing. The Quorum project had this problem, and it’s another reason why they went with the dummy window handles. They’re using GLFW, which doesn’t have a way to plug in a handler for the WM_GETOBJECT window message (required by UIA). The Quorum developers were in awe when I reached for a somewhat obscure Win32 hack, window subclassing, to work around the problem. To be clear, I don’t claim to be a Win32 wizard. But I suppose the set of developers who have my level of understanding of Win32 is small and shrinking. So that’s a problem for a toolkit developer that wants to implement accessibility on that platform.
Immediate-mode GUIs add their own challenges, because they don’t have a persistent tree of objects, which the major accessibility APIs basically assume. Some of them don’t even have a unique, persistent identifier for each element, which I think is a requirement for implementing accessibility APIs.
I’ve been thinking for a while about creating a multi-platform abstraction for accessibility, so developers of small toolkits don’t have to implement UI Automation, AT-SPI, Cocoa accessibility, etc. from scratch, just as they can work with OpenGL and SDL for graphics and input. I’ve been talking about the problem long enough. I plan to do something about it sometime this year. One of the reasons I left Microsoft is so I can, sooner or later, work on projects like this one with no conflict of interest.
It’s nice, and I respect rxi. But this has no AT-SPI 2 integration, nor libatk integration. So you’d have to hand-roll any accessibility yourself.
Would you really expect that in 1100 lines of C code?
If some developer, trying to fight the rising tide of complexity, develops an app using this or a similar toolkit, for a task that doesn’t have inherent accessibility barriers, and as a result some blind person (or person with another disability) can’t do their job, I won’t care how few lines of code the toolkit required. Some problems are inherently complex, and developing a user interface that accommodates the full range of human abilities and needs is one of them. Yes, software complexity often gets out of control, but sometimes we react to that by going too far in the other direction.
P.S. Yes, I’m assuming a world of opaque, proprietary applications that people are compelled to use to make a living. In a world of free software and open protocols, I suppose this wouldn’t be such a problem.
I do think there is a place for very simple software. Even if it isn’t a good idea to use it in a general setting, it still provides a great opportunity for people to learn about topics. It would be very scary to learn about compilers if the only available reference was GCC.
To be clear, I don’t think that you are advocating for the removal of projects like microui. I just want to provide an alternative view on the usefulness of the project.
libatk is not that difficult to deal with, full atk reference here. For LibreOffice, the interface is extremely small, despite how complex the LibreOffice GUI source is (For this it would probably only be a few hundred more lines – hardly a tradegy!). Also this (Accerciser) is a good tool to check just how Accessible your app is.
It is, quite frankly, amazing that I have a ‘troll’ downvote. As in, it amazes me how little people give a shit about others. As mwcampbell noted, these small toolkits are often attractive to in-house development, and small developers who do not wish to work with ‘bulk’.
I am a fan of small software, I’ve also been familiar with rxi’s stuff “before he got popular” (And knew him somewhat, a long time ago), I know and agree with the goal he intended here. However, that does not mean that this software gets a free pass for excluding users that are disabled. And if you intend to have universal accessibility, where else would you implement it? It’s either implementing it on this layer, or forcing every other downstream software package to implement it from scratch, which is clearly ludicrous.
I hesitate to write this, because I also don’t want to excuse inaccessibility. But I understand why it happens, and think it might be worth providing some explanation.
First, it’s not clear to me whether ATK can be used independently of GTK. Also, GTK 4 has stopped using ATK; now it implements AT-SPI directly. So it seems to me that ATK is deprecated.
In any case, both ATk and AT-SPI are only relevant to the tiny fraction of users who use one of the Unix-based free desktops. Implementing either of these won’t help users on Windows, Mac, the mobile platforms, or the browser (via WebAssembly).
And ATK might be one of the saner accessibility APIs to implement. While I was at Microsoft on the Windows accessibility team, I spent two of our annual Hackathons helping a non-profit group (the Quorum educational programming language project) with their implementation of the Windows UI Automation API. I saw just how badly they could screw up their UIA implementation, not due to incompetence, but just because they’re not experts in Win32, COM, and UIA itself. I eventually found out that they used some old Windows SDK samples as a starting point. Microsoft’s own sample implementations of UIA encourage practices that are bad for most modern toolkits. For example, the samples assume that each control has its own OS-level window handle. That’s fine for a sample with a single control, but not for a full toolkit. So the Quorum folks figured they should create dummy window handles for all the controls. I spent most of the first Hackathon correcting that design flaw. Unfortunately, a good UIA sample needs to either be based on a real GUI toolkit or implement one of its own. If I had stayed at Microsoft, I probably would have spent my next hackathon creating that sample. I might still do it on my own time at some point.
Another challenge is how to expose your platform accessibility implementation(s) if you use a cross-platform abstraction layer like SDL or GLFW to handle input and windowing. The Quorum project had this problem, and it’s another reason why they went with the dummy window handles. They’re using GLFW, which doesn’t have a way to plug in a handler for the WM_GETOBJECT window message (required by UIA). The Quorum developers were in awe when I reached for a somewhat obscure Win32 hack, window subclassing, to work around the problem. To be clear, I don’t claim to be a Win32 wizard. But I suppose the set of developers who have my level of understanding of Win32 is small and shrinking. So that’s a problem for a toolkit developer that wants to implement accessibility on that platform.
Immediate-mode GUIs add their own challenges, because they don’t have a persistent tree of objects, which the major accessibility APIs basically assume. Some of them don’t even have a unique, persistent identifier for each element, which I think is a requirement for implementing accessibility APIs.
I’ve been thinking for a while about creating a multi-platform abstraction for accessibility, so developers of small toolkits don’t have to implement UI Automation, AT-SPI, Cocoa accessibility, etc. from scratch, just as they can work with OpenGL and SDL for graphics and input. I’ve been talking about the problem long enough. I plan to do something about it sometime this year. One of the reasons I left Microsoft is so I can, sooner or later, work on projects like this one with no conflict of interest.
Big fan of https://github.com/Immediate-Mode-UI/Nuklear . Very glad there is some new flavors in this field, will check it out.
It’s not in C, but have you already checked out https://gioui.org?