TIL: The Windows SDK ships an import library for ntdll.dll. I don't know how long that has been going on. I thought ntdll was undocumented, and something that Microsoft didn't want applications to use directly. But now the Rust standard library uses a few functions from it, e.g. NtWriteFile. I wonder if that's going to be a problem for any users of #AccessKit, particularly non-Rust projects using the C API.
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/?
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/?
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.
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.
#AccessKit question. I'd like to recommend this to developers so they can make their projects more #accessible. I noticed there's no documentation. Is it easy enough to learn without the need for documentation? If not, I'm hesitant to recommend something that I know developers are going to struggle with. It's tough enough asking them to make their apps accessible when they don't know much about us, let alone asking them to learn a new library with no docs. #Accessibility#Blind#VisuallyImpaired
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.
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.
@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.
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).
Question for developers that work with macOS: Anyone know if there's an easy way to take a single, self-contained executable and package it as an app bundle, with just enough Info.plist entries and other stuff to make it runnable? I discovered that when running an unpackaged executable in Terminal, any windows created by that executable are invisible to Accessibility Inspector. This issue, while not specific to #AccessKit, does affect AccessKit users wanting to test their work.
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?
The #AccessKit C API should now be usable for cross-platform projects, thanks to CMake support and a cross-platform SDL-based example, both contributed by my colleague Arnold Loubriat. Check out the new release, complete with prebuilt libraries for all supported platforms (both static and shared). https://github.com/AccessKit/accesskit/releases/tag/accesskit_c-v0.5.0
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.
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.
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 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.
> #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.
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.