Hacker News Reader

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

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

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.

Sounds like a good solution. Thanks for taking the initiative to look into this already!

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

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

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

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

Can 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?

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

How 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?

That'd be fine, especially considering that someone else could write their own GUI front-ends for your utilities.

you can recommend a cross-platform C library for the accessibility support.

Not 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 [2]: https://github.com/williamhunter/pascal-bindings-for-c

Why people do that? It is always a good learning experience.