4 ms·

> 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

> 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.
- badsectoracula 9y ago
  Oh i see, sorry about the misunderstanding then. > 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. I'll need to look into it, if i go into that route i'll most likely make it an optional build-time feature that is enabled by default if the relevant header files are found and try to load it dynamically instead of making it a plugin (the toolkit can be compiled as a static library to create self-contained executables). This is also what i'm doing with OpenGL support that may not always exist - the toolkit and application work, it just disables the OpenGL stuff. But this is something i'll check in the future, at the moment the toolkit is barely usable even by people with perfect sight :-P.
  - mwcampbell 9y ago
    Sounds like a good solution. Thanks for taking the initiative to look into this already!

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.

badsectoracula 9y ago
Oh i see, sorry about the misunderstanding then. > 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. I'll need to look into it, if i go into that route i'll most likely make it an optional build-time feature that is enabled by default if the relevant header files are found and try to load it dynamically instead of making it a plugin (the toolkit can be compiled as a static library to create self-contained executables). This is also what i'm doing with OpenGL support that may not always exist - the toolkit and application work, it just disables the OpenGL stuff. But this is something i'll check in the future, at the moment the toolkit is barely usable even by people with perfect sight :-P.
- mwcampbell 9y ago
  Sounds like a good solution. Thanks for taking the initiative to look into this already!