4 ms·
Like most other less-popular GUI toolkits that aren't just wrappers over the host platforms' native widgets, this one is inaccessible to people with disabilitie
by mwcampbell 9y ago
Like most other less-popular GUI toolkits that aren't just wrappers over the host platforms' native widgets, this one is inaccessible to people with disabilities, such as blind people (who use a screen reader). To fix this, toolkits like this one need to implement each host platform's accessibility API. On Windows, that's UI Automation; for Unix, that's AT-SPI. This is a lot of work, but it's necessary if the toolkit is going to be used for any software that might be important for a job, education, or generally living one's life.
To anyone else thinking of developing your own GUI toolkit, please reconsider. It would probably be better for you to just use one of the established ones, unless you have the resources to flesh out all of the tedious but important stuff like accessibility.
Edit: I'm sorry if I offended any developers or sounded like I was devaluing your work. That wasn't my intent, and I actually tried hard to keep the tone of this comment under control. It's just very frustrating every time I read about yet another inaccessible GUI toolkit.
- daveguy 9y agoReconsider, but hopefully this will encourage the developers to address accessibility. I think it is important that automation is considered in the same category as accessibility. Automation could lead to great strides in accessibility.
- mwcampbell 9y agoCan you expand on what you mean by automation? Do you mean something like the Windows UI Automation API, which is an accessibility API that doubles as a way to automatically test UIs? Or do you mean something more like COM Automation or AppleScript?
- daveguy 9y agoAll of the above. I believe automation apis such as windows UI automation, COM or applescript all contain valuable information for accessibility (some more than others). Whether that is simply all the text displayed on the screen (not that getting that done is simple) or conversion of a complex series of mouse clicks into a simple operation. I think system automation apis are comparable to accessibility apis. As one improves so should the other. Would be interested in discussing further.
- diaz 9y agoAs someone that has an amazing work colleague that is blind but also an amazing software developer, I very strongly agree with the idea of your comment. I'm genuinely annoyed and sad when I'm dealing with shitty UI/UX and realize that something may be completly unaccessible for his use. He made me more aware of the general problems and it's something I always keep in the back of my mind when explaining or doing things (things like pictures, diagrams, white board drawings, etc are a no-no). I would like to see more people aware and thinking of this and not forget of the issue for new experiences with new UIs.
- badsectoracula 9y ago> for Unix, that's AT-SPI Some time ago i looked into this since i am creating a toolkit (unrelated to the linked one) and thought that it would be nice to add some accessibility support - at least for screen readers. Unix doesn't have an accessibility API nor does X, AT-SPI is basically GNOME's version which works via ATK and/or D-Bus. D-Bus is not an acceptable requirement for my case since it is a system that adds a lot of extra unnecessary complexity and implementing ATK (like Firefox) does is an even bigger no-no And really the only thing that uses AT-SPI is Gnome's Orca (KDE users use that too) and that project doesn't look very healthy (lots of bug - including several major bugs that are there for years, the wiki is a mess that has notes from 2011 about "cleaning it up"). So i just dropped the idea since it doesn't seem to be any way for this to work with X itself - nobody bothered to specify any protocol that works with pure X. It is something i might look into myself in the future, but honestly it is not a big priority for me. > This is a lot of work, but it's necessary if the toolkit is going to be used for anything other than games or toys. There are a ton of programs that do not provide accessibility features tech and are not games nor toys (in fact i'd guess that the majority of programs you'd find in a Linux distro do not provide anything like that - and a quick look at Orca's bugtracker makes it clear that even those that seem to do it have many issues). Also i think you'd have a better response from the people who are writing the actual code if you aren't trying to devalue their work by calling it games and toys. > It would probably be better for you to just use one of the established ones, It would be even better if the established toolkits didn't suck as much and broke their APIs every 2-3 years, making the programs that depend on them have a shorter lifespan than the supported versions of Windows (let alone reaching a point where they can even dream about Windows' backwards compatibility).
- mwcampbell 9y ago> trying to devalue their work by calling it games and toys. I'm sorry; that's not what I meant to do. I only meant that I know it's not reasonable to expect developers of games and other software that's just for fun to go out of their way to implement accessibility. But for any software that might be used in a job, for education, for interacting with a company or government agency, or even for communication in general, accessibility is really important. I know a blind guy who almost lost his job because he couldn't use a specific piece of inaccessible software; he only kept his job because the company found something entirely different for him to do. And yes, a lot of important software is not accessible. We need to change that. About AT-SPI and D-Bus, could you implement AT-SPI support as a plugin, so it's there for those who need it but doesn't add D-BUS as a hard dependency? That's what Qt does.
- lcsoft 9y agoIn the past, the author found the word "accessibility" from the example code in the Boostrap.css documentation, and the author has considered let LCUI support accessibility, but the author's free time is limited, So before the stable version is completed, the main task now is to make the project functions work stably.
- lcsoft 9y agoyou can recommend a cross-platform C library for the accessibility support.
- avhon1 9y agoNot C per se, but FreePascal's LCL library has native accessibility support [1], and there are plenty of examples showing how to mix Pascal and C [2]. [1]: http://wiki.freepascal.org/LCL_Accessibility http://wiki.freepascal.org/LCL_Accessibility [2]: https://github.com/williamhunter/pascal-bindings-for-c https://github.com/williamhunter/pascal-bindings-for-c
- knowThySelfx 9y agoWhy people do that? It is always a good learning experience.
- ckocagil 9y agoWhile this is true, I think focusing on _implementing_ accessibility from the get go is a bad idea. You should instead design the toolkit so that you have an idea of how it could be implemented in the future and if the toolkit gets popular.
- mrtweetyhack 9y agoNeed? No. Nobody needs to do anything.
- loup-vaillant 9y agoHow about forgetting about GUI altogether? To keep things concrete, I intend to write a file encryption utility and a password manager. The first versions will be command line programs. But of course, over 90% of computer users have this "unable to command line" disability, so they need a GUI. I was thinking of writing my own. Small, simple, and completely oblivious to accessibility issues—except maybe font sizes. Would that be okay? I mean, who cares about GUI accessibility if you can do the same thing on the command line? Unless the command line is not accessible for some unfathomable reason?
- mwcampbell 9y agoThat'd be fine, especially considering that someone else could write their own GUI front-ends for your utilities.