What does HackerNews think of accesskit?
UI accessibility infrastructure across platforms and programming languages
Just to make sure I'm not being one of those people: What AccessKit [1] has now, across Windows, macOS, and Linux, took roughly six person-months of work. We still need to support more widget types, especially list views, tables (closely related), and tree views, but we do already have text editing covered on Windows and macOS. Perhaps it helps that I'm an accessibility expert, especially on Windows. Anecdotally, it seems that implementing UIA from scratch is daunting for non-experts. But I guess in the big picture it's really not that hard.
This is a terrible decision that is going to bite them in the long run. Doing things this way makes it far, far more difficult to implement accessibility, and regulations on this are only going to get stricter.
Implementing accessibility for a framework like that would involve three separate implementations for three separate platforms and the need to interface with D-Bus, COM and Objective C, from Java. I imagine that the latter two would be particularly difficult, considering how bad Java's FFI support is. It's not just calling methods either, you'd actually need to implement your own classes that conform to the relevant COM interfaces / Objective C protocols. There are libraries that can help with this[1], but I don't think they would work particularly well for something as complex as a code editor.
I wonder if it's important to expose something close to each platform's accessibility API to sandboxed applications, or only the cross-platform abstraction over those APIs. For the latter, my AccessKit [1] project might be worth looking at.
There is now support for AccessKit (https://github.com/AccessKit/accesskit) which brings accessibility to egui (a first for an immediate mode GUI?).
There is also better table support, nicer keyboard shortcut handling, better looking text in light mode (still not great, but better).
See more in the changelog: https://github.com/emilk/egui/blob/master/CHANGELOG.md
Try it out at www.egui.rs
There is ongoing work to integrate AccessKit (https://github.com/AccessKit/accesskit) which will improve things significantly.
This is a tangent, but the implicit assumption that the UI is visual is just begging for a response from an accessibility perspective, so here goes.
Accessibility is very much an afterthought in native GUIs, not only in Cocoa, but also in Windows with the UI Automation API, and AFAIK with other native accessibility APIs as well. With these APIs, the assistive technology (e.g. screen reader) pulls information from the application (usually via the GUI toolkit), through repeated calls to methods defined by the accessibility API. Often the AT has to do several such calls in a row (and those often translate to multiple IPC round trips, making things slow). And the UI might change between such calls; there's no guaranteed way to get a consistent snapshot of the whole thing, as there is with a visual frame. On the application/toolkit side, these methods may return different responses from one call to the next, and the application or toolkit has to fire the right events when things change.
The web improves on this, in that accessibility information is conveyed through HTML tags and attributes. And yes, this is included in the output of a React component's render function. So while in practice, implementing accessibility may still be an afterthought, it's not an architectural afterthought as it is in native platforms.
One of my goals in AccessKit [1] is to work around this shortcoming of native accessibility APIs, particularly for developers of cross-platform non-web GUI toolkits. In AccessKit, the toolkit pushes a full or incremental accessibility tree update to the AccessKit platform adapter, which maintains the full tree in memory and uses that to implement the platform accessibility API. This even works for immediate-mode GUIs, as one can see in my proof-of-concept integration with the Rust egui toolkit [2].
[1]: https://github.com/AccessKit/accesskit I know I haven't yet done much with it this year. Hopefully I'll start doing substantial work on this again in the next few weeks. Threads like this one remind me that the world is waiting.
Perhaps the greatest of all programmers produce redundancy while depending on very little of it in their own code. For example, Richard Hipp created SQLite, the ubiquitous and amazingly high-quality embedded database, in C. Thinking about that makes me feel like I ought to be using C in my own, much more modest attempt at a reusable infrastructure project [1]. Cue the cliches about younger generations (like mine) being soft compared to our predecessors.
[1] https://github.com/AccessKit/accesskit (it's too late now, I'm committed to doing it in Rust)
Glad to hear it! I'm working on a Rust GUI accessibility library that might interest you:
https://github.com/AccessKit/accesskit
If you'd like to email me so we can compare implementation approaches and perhaps avoid duplicated effort, my email address is in my HN profile.
Edit to add: The article did also mention that accessibility is a must-have feature, though I can't remember now if that bit was there in the original. Sorry if it was.
Accessibility and internationalization are really hard though, right?
I'm finally doing something about the accessibility issue: https://github.com/AccessKit/accesskit Still have a long way to go though.
If I understand the synopsis of that article correctly, I don't think that concept applies here. Unless I've got my history wrong, our dominant standard for what's considered free software or open source, the Debian Free Software Guidelines (later repackaged as the Open Source Definition, wasn't the result of some kind of broad consensus among developers, users, and/or distributors. As badsectoracula pointed out [1] [2], source-available licenses with restrictions used to be more common. But Debian was always strongly aligned with the FSF's ideology; if I'm not mistaken, it was originally funded by the FSF, and of course, the full name of the main Debian distro is Debian GNU/Linux.
> The unusual foibles and preferences of specific people who are firmly in the history of FOSS are not relevant factors here. The relevant factor is drawing and maintaining a strict definitional line
My point is that this strict definition reflects nothing more than the MIT AI Lab hackers' elevation of their freedom (even at the expense of others, as in chapter 5 of _Hackers_) to an ethical absolute. Of course, most of those hackers outgrew that, but Stallman didn't, and he successfully spread the idea that all generally useful technical information, including software, should be freely available. And, if I'm not mistaken, that's where the DFSG came from. Since I didn't spell out part of my logic in my original comment, I will here: given that his nearly-forgotten campaign against passwords was obviously hopelessly naive, we should be open to the possibility that the same holds for the idea that software should be free for everyone to use.
> There's been a massive push in recent decades towards permissive licenses
Fair point. And I admit that this has made me stop and think about my choice of license for my own primary open-source project, AccessKit [3]. I was quick to permissively license that project from the beginning, before I considered funding. As it turned out, most of my development on that project so far has been funded by Google, which also specifically requested the Apache license (I went with the Apache/MIT dual license common in the Rust world). But in any case, I think a permissive license is actually the best choice for my goal with this project, which is to encourage and help developers to make as many GUI applications as possible accessible to disabled users. So yes, I want frictionless adoption above all else, but I think it's for a good reason. If a massive company used my project without paying me, I think I would consider it a net positive, because at least more applications would be accessible. But then, it's possible that by choosing a permissive license, I'm further poisoning the well, because I'm making more software available to freeloaders who would otherwise be obligated to pay someone (not necessarily me). FWIW, I'm thinking about developing an AccessKit-based module that has more of a niche use case (a screen reader for platforms or embedded devices that don't already have accessibility support), and for that, I might go with a dual copyleft/commercial licensing scheme.
[1]: https://news.ycombinator.com/item?id=29928956
There is AccessKit [1] that tries to create a cross-platform API to make this less tedious, but I'm not sure how far along that effort is.
Nothing can ever beat the accessibility of a fully native UI, written with whatever toolkit is most popular on a given operating system. Yes, this means you need multiple completely different UIs, 1Password 7 style.
If you want to go cross platform and still be accessible, go with Electron. There's a lot of material written already on how to make web apps accessible, and that's basically what Electron is. Chromium's accessibility is top notch on Windows and Mac OS and pretty good on Linux (if you turn on a flag).
If, for whatever reason, you're not allowed to use Electron, QT and WX widgets also work, though there are certain controls that don't work that well on certain platforms, so you might need some really terrible workarounds. Same for Swing, which still requires enabling Java Access Bridge if I'm not mistaken.
I think the worst offender is GTK, it's pretty accessible on Linux, but completely inaccessible on anything else. The GTK developers have been promising changes in that regard for years, but I haven't seen those changes yet.
Custom toolkits, SDL based libraries and immediate mode GUIs are a complete no go. The operating system needs to know what kind of controls you have on the screen for a screen reader to work, but "draw a bunch of pixels here" is definitely not enough information, and that's what you get from those. You can implement each platform's accessibility APIs yourself, but that requires intimate knowledge of the platform internals (think COM on Windows) and is often poorly documented (there's almost no documentation for the Mac APIs). If you want to go that route, it's much easier to just go with 3 separate GUIs.
There's some ongoing work to change that state of things[1], but it's far from complete.
Neat! I really like the Rust ethos of creating modular cross-platform adopters (e.g. winit, getrandom), and from a brief skim this seems to fit that model.
Some of us can't wait. That's why I, for one, continue to advocate for developers to make their applications accessible with the currently available tools. It's also why I'm trying, with my AccessKit [1] project (which admittedly is taking time to get off the ground), to make it easier for GUI toolkits to implement the current baroque platform accessibility APIs.
I'm also reluctant to concede that we're doomed to reconstruct UI content and semantics probabilistically from pixels, when that information is already there somewhere in the app. But it may be the best long-term solution to the social problem of trying to get everyone to implement accessibility.
https://github.com/AccessKit/accesskit
Edit: I'll be spending next week working on a prototype, so I'm confident that I'll soon have something real to show.