3 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 think

by mtzet 5y ago

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. It's not at all clear to me that the right approach is to have both the accessibility interface and the GUI be generated from the same components. It seems to me that it's just approaching the lowest common denominator of a passable GUI and a passable accessibility interface. The traditional widget-style GUI paradigm asks you to essentially copy all your application data into their format and to keep this format in sync with your own data. This is tedious, and I believe hinders the creation of better GUIs. On the flip-side, owning your data structure means it can indeed hook into the accessibility API for you. Immediate mode GUIs provide an alternative approach, where they only handle rendering stuff on screen. Since all the data structures are now properly controlled by the programmer, it is much easier to create dynamic GUIs. Taking a step back like this provides an opportunity to further the state of the art. The solution I see to providing accessibility in immediate mode GUIs is that the programmer has to hook into the accessibility API themselves -- if it makes sense. It's not clear to me that certain advanced GUI programs can ever be very accessible. Yes, this is more work, but there's also an opportunity to create richer experiences for people with disabilities.

mwcampbell 5y ago
> 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.
CJefferson 5y ago
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.
zxzax 5y ago
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.

by mtzet 5y ago

mwcampbell 5y ago

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

CJefferson 5y ago

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.

zxzax 5y ago

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.