Yesterday in #LibrePlanet chat I named the #Makepad project, a real adorable 😍 effort that's still lacking on the #a11y side, i.e. could do with some #AccessKit on board.
Today I found out that Makepad is apparently part of a #Rust appdev effort, called #Robius. Another project here is #Dioxus.. also in for @accesskit#accessiblity support.. maybe. 🤔
Robius looks like a very loose conglomeration of independent projects. Maybe AccessKit is even a fit to it?
> #a11y has long been confined to only a handful of the largest, most well-resourced UI toolkits, leaving a large proportion of #FreeSoftware inaccessible to disabled people. AccessKit [provides] an accessibility abstraction and glue layer that can be reused by many toolkits across programming languages.
TIL; iOS allows accessibility elements to have non-rectangular bounds, using bezier paths. Clearly I should add that feature to my #AccessKit cross-platform library (no, AccessKit isn't an Apple thing).
Just saw that the Zed code editor (https://zed.dev/) is now open source. It's written in Rust and has its own GUI toolkit, called GPUI. Doesn't look like they've done any work on accessibility yet. Hopefully they'll see fit to spend time integrating #AccessKit soon.
I wonder if the Linux/free desktop ecosystem will eventually hit a tipping point where new applications and toolkits exclusively target Wayland, and users who stick with X have to run a rootless Wayland compositor on top of their X session, as opposed to Wayland users running a rootless X server (Xwayland).
My new accessibility architecture is certainly Wayland-first, if not Wayland-only. It looks like the protocol that toolkits need to support is going to be way simpler than AT-SPI, and for #AccessKit, it would certainly be attractive to not have to bloat the code with either a new fallback protocol for X, or the old AT-SPI.
I want to do an overhaul of the #AccessKit project website (https://accesskit.dev/). The current site is kind of broken, but more than that, I want to do a static site with source in Git, not WordPress. The site contains a blog, but it's not just a blog. I haven't yet decided whether tutorial/narrative documentation should be part of the same site or on a separate docs site. The theme needs to prioritize accessibility but also not be ugly. I'd gladly pay someone to work on this.
@weirdwriter The AT-SPI protocol actually provides a way for ATs like Orca to automatically tell applications when accessibility needs to be enabled, as long as the desktop environment is correctly configured. I don't know if there are applications or toolkits that still don't support this mechanism. I know it's there because we just implemented it in #AccessKit.
One of my major role models, though we never met, was the team at the pioneering assistive technology company Syntha-voice, which shipped the first ever Windows screen reader in 1992, without ever asking Microsoft a question. When I heard about this in @JonathanMosen's interview with David Kostyshyn in 1999, it made a lasting impression on me. I think this largely explains my propensity to solve problems using ugly workarounds rather than trying to cooperate with other developers.
This came to mind just now because I was thinking about how I implemented integration between #AccessKit and the Rust winit library. I did a direct integration in a fork of winit as a proof of concept, but rather than try very hard to get that code upstreamed, I ended up hacking around the lack of interest from the winit team by implementing Win32 subclassing on Windows and the ObjC runtime equivalent on macOS.
Thanks to some excellent work by Arnold Loubriat, #AccessKit now has Python bindings. https://pypi.org/project/accesskit/ This will be useful for GUI toolkits where the widgets are actually implemented in Python, such as Kivy or UIs on top of Pygame, as opposed to Python wrappers over C/C++ toolkits or platform widgets. Documentation is still pretty thin, but there's a pygame-based example in the source distribution.
I should also thank everyone who has worked on PyO3 (https://pyo3.rs/v0.20.1/), which makes it much easier to write Python extension modules in Rust. If Java had something equivalent, my Java bindings for #AccessKit would probably be done already.
Hi friends; recently found out an HPC programmer colleague has developed really bad RSI to the point of no longer being able to use a mouse/keyboard.
He’s been trying to use Dragon speech to machine, but when it takes (his words) “nearly 30 minutes to CD & LS a directory, [its effectively impossible to work]”
I was wondering if anyone was familiar with similar cases and what tools they’d found and used to deal with this set of problems
@fclc My understanding is that the best tool for programmers who need to use an alternative input method is Talon (https://talonvoice.com/). I haven't yet tried it myself, but have chatted some with the lead developer; he's using my #AccessKit library to make the Talon UI itself accessible.
It's tempting to reduce the compiled size of one's software by excluding debug info from release builds. For end-user apps, it makes sense to exclude the debug info from the main distribution, and for proprietary software, to keep it to oneself. But for pre-built binaries of open-source libraries, like my #AccessKit project, I think we have a duty to include debug info in the build and pass it along, so the ultimate app developer can debug issues in release builds if they need to. Thoughts?
I can't stop wondering if, to truly meet my goals for the #AccessKit project (https://github.com/AccessKit/accesskit), it will be necessary to rewrite it as a C library. Not a Rust library with a C API, but actually in C. I've had doubts before; you'd think the question would be settled by now. But two things prompted me to think about this again. 1/?
I occasionally have to remind myself, when promoting my #AccessKit project, that what really matters isn't whether developers use AccessKit, but that they implement accessibility one way or another. AccessKit isn't always the best solution. For example, it may be overkill for a project that's only targeting the browser but is still rendering the UI in a canvas. In that case, it may be simpler to create the hidden HTML elements directly rather than going through a layer of abstraction.
Question for folks who are knowledgeable about machine learning and specifically computer vision: Realistically, are we anywhere close to the point where a computer can look at the actual pixels in a camera feed or even a direct stream of on-screen output, understand the image, and provide to a blind person all of the information that a sighted person can see? This would, of course, be the ultimate technological solution to all accessibility problems for blind people. 1/?
I sometimes wonder if I'm solving a 2000s problem, so to speak, with my work on #AccessKit. That is, accessibility for non-web, desktop GUIs is quite an old problem by now, and AccessKit is simply trying to provide a reusable, toolkit-independent version of the sort of cross-platform accessibility abstraction that has existed (within browser engines and big GUI toolkits) for a couple of decades. It's certainly not a trendy thing to be working on. But still undeniably useful. 5/?
Also, while Arnold Loubriat (the other main #AccessKit developer) and I were together in Albuquerque, where we met in person for the first time, we worked on the web platform adapter for AccessKit. This is specifically for web applications that render their UI to a canvas. We ran into an unexpected complication at the end, but the results so far are promising.
My #RustConf talk about #AccessKit yesterday went pretty well, though it went a few minutes over, and I'm pretty sure my conclusion in particular was too long. Not exactly looking forward to listening to the recording when it comes out, but I know I should.
The freedom of the free desktop ecosystem (what we often colloquially call "desktop Linux") is a double-edged sword. It has been the source of some angst for me in the #AccessKit project, which I still haven't figured out how to resolve productively.
On Windows, there's one documented way to implement the UI Automation API, and that's using the UIAutomationCore DLL. Same goes for NSAccessibility and the ObjC runtime on macOS. Depending on a C library is a given. 1/?
One of my personal design guidelines for #AccessKit, which I really should write down somewhere more durable, is this: Given a choice between what's easier for accessibility providers (GUI toolkits and applications) and what's easier for consumers (AccessKit platform adapters today, maybe ATs themselves in the future), always favor the providers. That's how we make more stuff accessible. I had to remind myself of that while doing some cleanup of properties and roles.
Just booked my flights for #RustConf in Albuquerque. I'll arrive in the evening on Monday, September 11, and will leave in the morning on Saturday, September 16. Looking forward to meeting my primary collaborator on #AccessKit, Arnold Loubriat, in person. Also looking forward to meeting lots of other developers.