Just discovered there was a Hacker News comment thread about a lean and mean desktop app written with its own cross-platform GUI toolkit, with nobody commenting on the total lack of accessibility. news.ycombinator.com/item?id=4… I had hoped that awareness of accessibility in the community had grown to the point that I didn't have to be the one to post about this everywhere. I just belatedly commented on this particular thread.
in reply to Matt Campbell

My immediate reaction to this was, to quote the fictional version of George Washington in _Hamilton_ ("Right Hand Man"), "I cannot be everywhere at once, people." To be fair, though, I don't think I've specifically asked for people to help evangelize my AccessKit project (accesskit.dev/) to the kinds of developers whom it's intended for.
in reply to Matt Campbell

So if you encounter an application whose UI is completely inaccessible with a screen reader, or even a single control/widget that's inaccessible, that could be a good fit for AccessKit (accesskit.dev/). We haven't yet reached version 1.0, so we still make breaking API changes from time to time, so it's still something for early adopters. But we do have C and Python bindings in addition to the Rust native API.
in reply to Matt Campbell

I'll also make this offer: If you're in doubt about whether AccessKit is a good fit for an application, I can take a quick look. The general rule is this: if a screen reader doesn't see any controls at all in the window, or if a given control is identified as "unknown", "custom", or the like with no other information about it, then that window or control is a good candidate for being made accessible with AccessKit.
in reply to Matt Campbell

I'm curious, have you heard of the iCue software from Corsair? Its their device management/control platform. Utterly and completely uselessly inaccessible. Does your AccessKit require integration with the source code of an application in order to function, or can it be layered on top of any inaccessible application? As in, would you need the developer's cooperation in order to use AccessKit to make it accessible, or at least try to?
in reply to Adam MacLeod

@adam I just took a quick look at that Corsair application. The application itself is using the Qt toolkit with lots of unlabeled buttons. So it should be straightforward for them to label the buttons. The installer is weird. It seems to be embedding Microsoft's UWP XAML toolkit in a desktop window, but in a non-standard way that makes it only sort of accessible.
in reply to Matt Campbell

Maybe I need to teach more people to diagnose the causes of desktop app inaccessibility, for starters, to do what I just did in another post on this thread, identifying what UI toolkit(s) an application is using so they can make a proper recommendation to the developer: toot.cafe/@matt/11404665605948…


@adam I just took a quick look at that Corsair application. The application itself is using the Qt toolkit with lots of unlabeled buttons. So it should be straightforward for them to label the buttons. The installer is weird. It seems to be embedding Microsoft's UWP XAML toolkit in a desktop window, but in a non-standard way that makes it only sort of accessible.

in reply to Matt Campbell

maybe up a meta-level here? You cannot, after all, be everywhere at once; we need more advocates teaching people about these problems, so maybe teach about how to teach about accessibility? Or make resources you can point to for different communities? Like “don’t use tkinter” was a big surprise for me as someone who has been doing Python forever; kind of shocking they still haven’t fixed it
in reply to Matt Campbell

Well man we're all trying to help each other out in some way or the other you know, the community is slowly pushing with you for accesskit, all be it the good chunck of us aren't programmers. In the game world we're trying to get a program called Godot to have accessibility, as well as push toolkits like IMGUI to have accessibility as a part of the todos on the list of improvements. Keep pushing on, and the community will do all it can to help!
in reply to Matt Campbell

Oh absolutely no! It's perfectly okay to feel like your work isn't counting, I am not a programmer but I am a designer, and I for sure feel that. You know how hard it is to want to make some things accessible, only to find the devs telling you that they're only going to work on it if this other project gets accessibility, so you have to do the entire walk around the mountain as they say, only to find that the popularity gaining UI toolkits have too much on the plate so accessibility keeps pushing further and further away. This is not to try to make you look invalid or anything, but for programmers at least they can work into source codes they can understand and do what they want. We designers who can't code have absolutely none of that, and our work is very much dependent on the programmers time and availability, especially since most programmers who do this work work with everyone elce over text, it's hard to really have a face to face as people to make bug testing and software accessible at a more fast speed.
in reply to Matt Campbell

I have found it much more workable though as I too also work and try to help bgt lover or also called the esoteric programmer and since we're cloce we contact over voice all the time for accessibility in apps, and I do try some times to give him help as to what a screen reader especially for Linux needs in the modern day and age. With his help we got the push to Godot accessibility started, as well as more work on KDE connect.
in reply to Matt Campbell

Yeah. User bruvgs is the programmer and advocate for Godot's accessibility as well, and through him we got the ball moving so to speak. With the first Stable version I will be making video and working with them in what ever way I can to make sure that not just writing code, but designing games are at the front of attention, as while it's good if blind people can code, it's even better if blind people can design a game like how much other people can.
in reply to Matt Campbell

One problem will be that most developers simply don't know accessibility APIs on any platform. So if they want to use AccessKit, there needs to be clear documentation of what's a button, checkbox, menu (which a lot of people get wrong on the web, for example), and such. So at the end, it is more likely that you or other volunteers will be implementing AccessKit support and hope that the maintainers won't break it in the future.
in reply to Matt Campbell

...And the developer of File Pilot, that inaccessible app I mentioned at the start of the thread, responded to my HN comment about accessibility and AccessKit:

> Hello! I can't promise anything on this topic yet, it's on my list, but it's fairly low priority right now. The program was written in C with no dependencies, so introducing a huge dependency like that isn't an option. But I appreciate the advice!

*sigh* Can't win them all, I guess. At least they said accessibility was on their list.

in reply to Matt Campbell

I haven't had the motivation to work on AccessKit, beyond what's required by my current contract, for a little while now. Seeing that new apps and UI toolkits are still being developed without accessibility has reminded me that the world is still waiting for me to finish solving this problem I set out to solve nearly 4 years ago. Nobody else is stepping up. I would actually like it if AccessKit had competition.

Zach Bennoui reshared this.

in reply to Matt Campbell

Well, it's not right to say no one else is stepping up. Arnold Loubriat has done a lot of work with me on AccessKit over the years. In particular, he has done most of the work on the AT-SPI implementation (for Linux or other free Unixes) and the C and Python bindings. And now I'm reviewing his latest pull request that I've let sit for too long.

Still, it's basically the two of us. No other similar projects that I know of.

in reply to André Polykanine

@menelion I definitely want to use Go, so that, for instance, the Gio immediate-mode toolkit can use it. C# would be good for Unity. We did a Unity proof-of-concept a few years ago.

We're talking about writing our own code generator, or maybe more of a code generation framework, to help us build out language bindings and particularly improve the documentation for non-Rust languages.

in reply to Matt Campbell

Well, that may be ambicious. Cross-platform accessibility API work is hard for most cases. I speak from experience having dealt with the Mozilla codebase for the better part of my professional career. If I hadn't had the knowledge from my prior work at Freedom Scientific, I would have been mostly stumped. This way, I at least knew what concept translated into what output, and what was expected by the screen reader. Of course, having the NVDA and ORCA sources helped a lot, too. But still, even having one such project like accessKit is quite an accomplishment. Not many people in our industry can pull this off, IMO. So wishing for a competing project is a stretch I think. There just aren't that many people who can do this on a pure technical level, and have the time and resources to do it.
This entry was edited (10 months ago)
in reply to Marco Zehe

@marco If you can muster any energy to help with AccessKit at all, that would be great. We're currently trying to figure out what we're doing wrong with listviews on macOS. See github.com/AccessKit/accesskit…

Of course, it's fine if you say no. I know you chose to retire early.

in reply to Matt Campbell

Well, for Linux, my knowledge basically stalled at the GNOME 2 level. Especially GTK 4 seems to be a whole new beast. And on MacOS, you basically have to read WebKit code to try and figure out what VoiceOver needs. But nowadays, I think the Firefox source code is also a big helpful resource to consider. The team has actually put in very good VoiceOver support into Firefox. Especially for these lists and tables, there need to be several arrays of column headers, row headers, rows, columns etc in a particular order I believe, to get this right. If you look under the Mozilla accessibility folder in the Mac and tests for Mac folders, you'll see how these APIS are tested and exercised to the death so they don't accidentally break. Before I got so sick that I had to retire, I worked on this, too, and must admit I'm very proud of the outcome for Firefox. I'd first have to somehow setup all that is needed to test that Slint app you were referring to in the issue, and since my exposure to Rust has been very limited, I expect a rather steep learning curve here. The accessibility code is all C and Objective-C, so not even SWIFT, and no Rust as far as I know. I'll try to take a look, but can't promise anything, but might bug you with questions on setting stuff up.
in reply to James Scholes

@jscholes @marco I was perhaps too deferential. In my original HN comment, I wrote, "Or if you'd rather just look at our code and implement the accessibility APIs yourself, that's cool too."

I know how much these "Handmade" project developers want to avoid bringing in third-party dependencies, especially dependencies written in anything other than C or old-school C++.

in reply to Matt Campbell

Fwiw, I really appreciate what you're doing here. I got reminded of this again recently because of a work-in-progress PR that's adding accessibility through accesskit to the Godot game engine, and this is not only making some developers interested in making their games accessible, but also because the godot studio itself uses Godot's uI functions there are now blind and sighted developers working on tutorials and plugins to make game creation with this engine possible. This will be the first time I'm aware of that we'll be able to use a very popular and cross-platform game engine for development, never mind all the possibilities this opens for reaching out to developers who use Godot for their games or applications. Same goes for other fields like music creation and audio plugin development, Rust is becoming more popular in that space so knowing I can point a developer at Accesskit if I come across an inaccessible audio plugin writen in Rust, or any other language really, is a gamechanger. :)
in reply to Matt Campbell

I stopped commenting on hn, especially about accessibility. Most were dismissive, some were quite insulting. But it also never helped. So I just stopped. I should find some quotes of replies I've gotten. It's... not pretty. And it's not because I wasn't nice. I always tried to be very respectful and understanding. It didn't make a difference. Obligatory of course there were people there that were understanding and who were on my side. But it just didn't feel like I was achieving anything.