Hacker News Reader

> This gets brought up pretty much every time immediate mode GUIs are discussed on HN. I think your comment is reasonable, and I don't disagree, but I also think it's important to not throw the baby out with the bathwater and dismiss immediate mode GUIs for accessibility reasons.

I can only talk about my own motivation for repeatedly bringing this up. If a developer is unaware that they're choosing an inaccessible GUI toolkit for their application, and that application is then required for a particular job, then that developer may end up unwittingly preventing some people from doing that job. And this isn't just hypothetical for me; I know of a blind person who lost his job (luckily only temporarily) because of an inaccessible application. So I think it's entirely reasonable for an application developer to dismiss a GUI toolkit because it's inaccessible. I wish more developers would research this on their own before choosing a toolkit for their applications. But since many don't, I feel obligated to draw attention to it. I'm glad I'm not the only one.

As for your suggestion that applications should implement the platform accessibility APIs themselves: First, it's impractical to expect application-level code to do this directly. The Windows accessibility APIs are notoriously hard to implement correctly. And my understanding is that the Mac, iOS, and Android accessibility APIs are only easy to implement if the application is written in the platform's native programming language. Now, these problems could be solved with an open-source wrapper library -- the SDL or GLFW of accessibility. And I'm planning to implement such a library myself sometime. But my plan is for that library to be used by toolkits, not applications. Because if every application has to directly implement accessibility in parallel with its GUI, then it's a safe bet that even fewer applications will be accessible. We want to get to a place where as many applications as possible can be accessible by default, with minimal effort on the part of the application developers.

I think there's a difference between asking applications to implement the accessibility APIs themselves and asking applications to use accessibility APIs provided by the OS.

A graphics application should be able to submit draw calls or queues to a OS subsystem that, for example, generates a comparable audio space, performs colorspace/size transformations for improving visibility, etc. Developers should just be responsible for plugging in to these systems, and the systems themselves should be as standardized as OpenGL, Vulkan, DirectX.

Applications don't have to implement this, the toolkit is supposed to handle it. It happens at the layer above Vulkan/DirectX, because those APIs are too low level and don't know anything window controls, text, etc. When applications disregard the platform's toolkit and use another toolkit that is not at feature parity with the one provided by the platform, they'll lose functionality. That's always been the case.

What I'm saying is that there should be a cross-platform standard like Vulkan or like the Document Object Model for accessibility. Toolkits should use implementations of that standard to enable accessibility like they use implementations of Vulkan or OpenGL to render graphics. In turn, applications should use the toolkits, as you've said.

I don't know if there is a "Khronos Group" for Accessibility Standards. Maybe there is.

I know people who use XCode through accessibility on Macs, and tell me it works well. Site, some things (3d graphics) are going to be hard to ever make accessable, but what exists is fairly good, if you just standard widgets. Blind people are using Macs and iPhones, and finding them highly effective.

I suspect most Devs would never link up and keep up to date an alternative accessibility interface. Also there is a lot of benefit to the accessable and standard interface being close, to make it easy to cooperate.

It gets brought up because, at least from my perspective, none of the immediate mode toolkits are addressing this. I understand the desire to keep the code simple and only handle the rendering, but that is fundamentally opposed to the way some assistive technologies work. They need to access the UI as a state tree to even make sense. If the goal with these toolkits is to always avoid storing state information, that isn't ever going to work with screen readers. You can't push this task to the app developer, it really needs to be tied to the toolkit's internal hierarchy and focus handling.

My opinion for the last several years has been, if you use these toolkits, you might just have to accept that your app is not going to be accessible and is not really suitable for anything beyond highly specialized use.