5 ms·

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

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

politician 5y ago
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.
- zxzax 5y ago
  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.
  - politician 5y ago
    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.
    - zxzax 5y ago
      IMO the closest thing to that is WAI-ARIA, the concepts apply anywhere.
      - mwcampbell 5y ago
        I think you're right. Unfortunately, that isn't very helpful for developers not using the web platform.

politician 5y ago

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.

zxzax 5y ago
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.
- politician 5y ago
  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.
  - zxzax 5y ago
    IMO the closest thing to that is WAI-ARIA, the concepts apply anywhere.
    - mwcampbell 5y ago
      I think you're right. Unfortunately, that isn't very helpful for developers not using the web platform.