5 ms·

Before you use this in your next important application, please read the comment on accessibility that I posted the other day on the LCUI thread: https://news.yc

Before you use this in your next important application, please read the comment on accessibility that I posted the other day on the LCUI thread: https://news.ycombinator.com/item?id=16329640 https://news.ycombinator.com/item?id=16329640

TeMPOraL 9y ago
Your note is good in general, but for this particular case, note this is an immediate mode GUI library. I.e. the kind of stuff that's primarily used in videogames. A typical game (or supporting tool) where this is included would already be not accessible (imagine playing e.g. an RTS with a screen reader).
- mwcampbell 9y ago
  Point taken. Some games, though, could be accessible if not for the way the UI was implemented. For example, repackaged text adventures. I downloaded the Lost Treasures of Infocom app for iOS, and it was completely useless with VoiceOver. Presumably because the dev at Activision who was working on this packaging used the same kind of UI toolkit that they always use for games. The same goes for turn-based strategy games, if it's feasible to provide text for all the graphics. Accessibility for games is definitely a much lower priority than accessibility for applications that are used in business, education, and everyday communication/social networking. Still, a blind person can feel excluded if their friends are playing a game that they can't play. Sometimes a given game can't be made accessible without changing the whole game mechanic. But that's not always the case. So, something to consider.
  - TeMPOraL 9y ago
    I agree. It's good that you bring this up, and also great you provided some extra context about why you're doing this in another comment.
bastijn 9y ago
Accessibility is always important to mention, which is why we should thank you for reminding us. In return, you have to understand that not every next important application will be used by blind people or people with disabilities, and as of such there is still room for people to develop new UI toolkits if they so please. Again, thanks for reminding everybody. People need to think about it. Your advice could be toned down a bit to “please think about your audience, if you expect people with disabilities to be part of it think twice when making your own UI toolkit, or at least factor in the costs to build in accessibility features.”
- gnud 9y ago
  Additional advice: "don't use this toolkit if you ever want to sell your product to government".
  - badsectoracula 9y ago
    TBH this looks mainly oriented towards games where usually the only UI accessibility you have to be concerned about is for people with color blindness.
    - microtherion 9y ago
      It's the only accessibility developers usually ARE concerned about, but in many games, it would be possible to do much better. Uncharted 4, for instance, is highly accessible: https://dagersystem.com/all-review-list/disability-review-uncharted-4/ https://dagersystem.com/all-review-list/disability-review-un...
  - pkaye 9y ago
    Which is interesting because I use a dialysis machine and these are essentially sold to the government instead of the patient yet they all use a custom GUI interface like this one. Far as I can tell there is no accessibility features.
    - mwcampbell 9y ago
mwcampbell 9y ago
Technical follow-up: It seems to me that implementing today's platform accessibility APIs (e.g. UI Automation for Windows, AT-SPI for Unix) would be difficult if not impractical for an immediate-mode toolkit like this one. These accessibility APIs expose a tree of UI objects, which the client (e.g. screen reader) can freely navigate and query. This basically assumes that there's a tree of UI objects in memory, which is the case for all mainstream toolkits as far as I know. But that's not the case for an immediate-mode toolkit. At least with Nuklear, the content and state of the UI (e.g. the label and current checked state of a checkbox) aren't stored anywhere in the toolkit's data structures. So I guess applications would have to play a very active role in implementing accessibility APIs, much more than they would with, say, Qt or even Win32.
- zxxon 9y ago
  >> This basically assumes that there's a tree of UI objects in memory, which is the case for all mainstream toolkits as far as I know. This is also the reason why they are a pain in the butt to use, at least from the perspective of an IMGUI advocate. Those people usually have a game development background, so they're used writing bespoke solutions for everything. Statelessness is a strength but also a big weakness, I doubt IMGUI will ever catch on its pure form. However, tools like React provide a fairly similar experience and they do produce object trees usable for screen readers. The missing piece here is something like a lightweight DOM for C/C++ projects.
Myrmornis 9y ago
I think your comments here and in the other thread are thoughtful and well-intentioned and are in general the right comments to make. However, I must admit that the incidents where UC Berkeley and other universities removed public access to many thousands of hours of videos of online undergraduate lectures severely reduced the extent of my sympathy for accessibility advocates. It sounds like a no-brainer to be sympathetic to the needs of disabled minorities, but in fact I would suggest that if the community of accessibility advocates wants to be successful in their aims, then they need to absolutely avoid being associated with the intellectual vandalism we saw at UC Berkeley and elsewhere.
- mwcampbell 9y ago
  What Berkeley did with its lectures is not the fault of accessibility advocates. I'll just point you to this comment from a blind friend: https://news.ycombinator.com/item?id=14580342 https://news.ycombinator.com/item?id=14580342
  - Myrmornis 9y ago
    I am not sure what you mean by "fault" but it was certainly the result of accessibility advocacy. I'm sorry but I disagree strongly with your blind friend. E.g. > this continuing trope of "OMG I didn't realize we needed to make our content accessible! Woe, woe are we!" passed through the realm of disingenuous and into that of pure bullshit a long, long time ago. They are just videos of a lecture. They can be put on the internet. EDIT: That sounds like I don't understand his point. I think I do: we've had decades to get used to the idea that content should/must be accessible, and of all institutions, a large public university should certainly be doing that now, in 2017. However, I just can't make myself accept it. They are just videos of a lecture. They can be put on the internet. Certainly they would be better if accessible, but once up it is vandalism to take them down.
    - mwcampbell 9y ago
      I think I understand why the outcome in this case frustrates you. Taking down the videos didn't do anyone any good, except that it was the easiest way out for Berkeley. Now, nobody has access to that information. So, one might argue that it's stupid that Berkeley was required by law to remove inaccessible content. But if that requirement wasn't there, the law would have no teeth, and other content wouldn't be made accessible. What we all wanted, of course, was for Berkeley to make the lectures accessible, not remove them. The fact that Berkeley removed them is Berkeley's fault, not ours. Your problem should be with Berkeley, not with us.
loup-vaillant 9y ago
Let's say I'm implementing an application blind users should be able to use (not an FPS game or drawing program). Aren't GUIs a pain in the butt even when properly implemented with the right accessibility hooks? How about writing a command line version of the program? Wouldn't that be much more accessible? I'm not even thinking ncurses, I'm thinking about a REPL, or even non-interactive like grep or awk.
- mwcampbell 9y ago
  Blind programmers and sysadmins sometimes prefer command-line tools. But most blind people are now thoroughly accustomed to GUIs. An accessible GUI can be very usable. IMO, it's much better than using a screen reader with a screen-oriented terminal application (ncurses or the like). If you're skeptical, I can put together a little demo of one or two use cases on Windows and/or the iPhone.
  - loup-vaillant 9y ago
    > IMO, it's much better than using a screen reader with a screen-oriented terminal application (ncurses or the like). I suspected as much, which is why I was thinking purely REPL/batch stuff. On the REPL end, I was thinking programming languages (Python, Lua, Lisp, OCaml…), and stuff like gdb. On the batch end, I was thinking utilities like grep or awk, compilers, or ImageMagick. In other words, stuff that would work well with a printer. I personally have a concrete use case in mind: file encryption, and password manager. I intend to write a first version for the command line, because it will be smaller and easier to write. Then I may do GUI versions. I was wondering to what extent the accessibility of the GUI version even matters, considering how simple the command line version would be.

TeMPOraL 9y ago

Your note is good in general, but for this particular case, note this is an immediate mode GUI library. I.e. the kind of stuff that's primarily used in videogames. A typical game (or supporting tool) where this is included would already be not accessible (imagine playing e.g. an RTS with a screen reader).

mwcampbell 9y ago
Point taken. Some games, though, could be accessible if not for the way the UI was implemented. For example, repackaged text adventures. I downloaded the Lost Treasures of Infocom app for iOS, and it was completely useless with VoiceOver. Presumably because the dev at Activision who was working on this packaging used the same kind of UI toolkit that they always use for games. The same goes for turn-based strategy games, if it's feasible to provide text for all the graphics. Accessibility for games is definitely a much lower priority than accessibility for applications that are used in business, education, and everyday communication/social networking. Still, a blind person can feel excluded if their friends are playing a game that they can't play. Sometimes a given game can't be made accessible without changing the whole game mechanic. But that's not always the case. So, something to consider.
- TeMPOraL 9y ago
  I agree. It's good that you bring this up, and also great you provided some extra context about why you're doing this in another comment.

bastijn 9y ago

Accessibility is always important to mention, which is why we should thank you for reminding us. In return, you have to understand that not every next important application will be used by blind people or people with disabilities, and as of such there is still room for people to develop new UI toolkits if they so please. Again, thanks for reminding everybody. People need to think about it. Your advice could be toned down a bit to “please think about your audience, if you expect people with disabilities to be part of it think twice when making your own UI toolkit, or at least factor in the costs to build in accessibility features.”

gnud 9y ago
Additional advice: "don't use this toolkit if you ever want to sell your product to government".
- badsectoracula 9y ago
  TBH this looks mainly oriented towards games where usually the only UI accessibility you have to be concerned about is for people with color blindness.
  - microtherion 9y ago
    It's the only accessibility developers usually ARE concerned about, but in many games, it would be possible to do much better. Uncharted 4, for instance, is highly accessible: https://dagersystem.com/all-review-list/disability-review-uncharted-4/ https://dagersystem.com/all-review-list/disability-review-un...
- pkaye 9y ago
  Which is interesting because I use a dialysis machine and these are essentially sold to the government instead of the patient yet they all use a custom GUI interface like this one. Far as I can tell there is no accessibility features.
  - mwcampbell 9y ago

mwcampbell 9y ago

Technical follow-up: It seems to me that implementing today's platform accessibility APIs (e.g. UI Automation for Windows, AT-SPI for Unix) would be difficult if not impractical for an immediate-mode toolkit like this one. These accessibility APIs expose a tree of UI objects, which the client (e.g. screen reader) can freely navigate and query. This basically assumes that there's a tree of UI objects in memory, which is the case for all mainstream toolkits as far as I know. But that's not the case for an immediate-mode toolkit. At least with Nuklear, the content and state of the UI (e.g. the label and current checked state of a checkbox) aren't stored anywhere in the toolkit's data structures. So I guess applications would have to play a very active role in implementing accessibility APIs, much more than they would with, say, Qt or even Win32.

zxxon 9y ago
>> This basically assumes that there's a tree of UI objects in memory, which is the case for all mainstream toolkits as far as I know. This is also the reason why they are a pain in the butt to use, at least from the perspective of an IMGUI advocate. Those people usually have a game development background, so they're used writing bespoke solutions for everything. Statelessness is a strength but also a big weakness, I doubt IMGUI will ever catch on its pure form. However, tools like React provide a fairly similar experience and they do produce object trees usable for screen readers. The missing piece here is something like a lightweight DOM for C/C++ projects.

Myrmornis 9y ago

I think your comments here and in the other thread are thoughtful and well-intentioned and are in general the right comments to make. However, I must admit that the incidents where UC Berkeley and other universities removed public access to many thousands of hours of videos of online undergraduate lectures severely reduced the extent of my sympathy for accessibility advocates. It sounds like a no-brainer to be sympathetic to the needs of disabled minorities, but in fact I would suggest that if the community of accessibility advocates wants to be successful in their aims, then they need to absolutely avoid being associated with the intellectual vandalism we saw at UC Berkeley and elsewhere.

mwcampbell 9y ago
What Berkeley did with its lectures is not the fault of accessibility advocates. I'll just point you to this comment from a blind friend: https://news.ycombinator.com/item?id=14580342 https://news.ycombinator.com/item?id=14580342
- Myrmornis 9y ago
  I am not sure what you mean by "fault" but it was certainly the result of accessibility advocacy. I'm sorry but I disagree strongly with your blind friend. E.g. > this continuing trope of "OMG I didn't realize we needed to make our content accessible! Woe, woe are we!" passed through the realm of disingenuous and into that of pure bullshit a long, long time ago. They are just videos of a lecture. They can be put on the internet. EDIT: That sounds like I don't understand his point. I think I do: we've had decades to get used to the idea that content should/must be accessible, and of all institutions, a large public university should certainly be doing that now, in 2017. However, I just can't make myself accept it. They are just videos of a lecture. They can be put on the internet. Certainly they would be better if accessible, but once up it is vandalism to take them down.
  - mwcampbell 9y ago
    I think I understand why the outcome in this case frustrates you. Taking down the videos didn't do anyone any good, except that it was the easiest way out for Berkeley. Now, nobody has access to that information. So, one might argue that it's stupid that Berkeley was required by law to remove inaccessible content. But if that requirement wasn't there, the law would have no teeth, and other content wouldn't be made accessible. What we all wanted, of course, was for Berkeley to make the lectures accessible, not remove them. The fact that Berkeley removed them is Berkeley's fault, not ours. Your problem should be with Berkeley, not with us.

loup-vaillant 9y ago

Let's say I'm implementing an application blind users should be able to use (not an FPS game or drawing program). Aren't GUIs a pain in the butt even when properly implemented with the right accessibility hooks? How about writing a command line version of the program? Wouldn't that be much more accessible? I'm not even thinking ncurses, I'm thinking about a REPL, or even non-interactive like grep or awk.

mwcampbell 9y ago
Blind programmers and sysadmins sometimes prefer command-line tools. But most blind people are now thoroughly accustomed to GUIs. An accessible GUI can be very usable. IMO, it's much better than using a screen reader with a screen-oriented terminal application (ncurses or the like). If you're skeptical, I can put together a little demo of one or two use cases on Windows and/or the iPhone.
- loup-vaillant 9y ago
  > IMO, it's much better than using a screen reader with a screen-oriented terminal application (ncurses or the like). I suspected as much, which is why I was thinking purely REPL/batch stuff. On the REPL end, I was thinking programming languages (Python, Lua, Lisp, OCaml…), and stuff like gdb. On the batch end, I was thinking utilities like grep or awk, compilers, or ImageMagick. In other words, stuff that would work well with a printer. I personally have a concrete use case in mind: file encryption, and password manager. I intend to write a first version for the command line, because it will be smaller and easier to write. Then I may do GUI versions. I was wondering to what extent the accessibility of the GUI version even matters, considering how simple the command line version would be.