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.

Well, not as an employee. I'm open to doing contract work on #AccessKit, as I have before.

IMO the default behavior goes too far in optimizing for beginners, or programmers whose background is in non-systems languages. Meanwhile, those of us who want to minimize our binary size are tempted to do dangerous things like use the nightly toolchain with unstable features, or perhaps take the nuclear option of going no-std for our binaries/DLLs and all of their transitive dependencies, even on desktop platforms. I've seriously considered both options for my #AccessKit language bindings.

This week I'll spend some time preparing my upcoming #RustConf talk on #AccessKit. https://rustconf.com/schedule/making-guis-accessible-across-platforms-and-languages-with-rust Any suggestions about how much content I should put on my slides? I want to use some kind of HTML-based or Markdown-based system for creating the slides, not something like PowerPoint, Keynote, or Google Slides.

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.

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

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'm speaking about #accessibility and #AccessKit at #RustConf! https://rustconf.com/schedule/making-guis-accessible-across-platforms-and-languages-with-rust

Many apps are inaccessible for blind/VI people. Developers usually have to implement #Accessibility features from scratch for each platform they develop on, which can scare them away. The good folks over @accesskit are trying to change that with their #Foss project, #AccessKit. Their goal is to create a cross-platform solution for accessibility that only has to be implemented once. I'm posting this to spread the word. Let's help them reach their goals! https://accesskit.dev/ #Blind #A11Y

#AccessKit now has a C API, which also makes it available to many other languages. Check out the header file, prebuilt libraries (both static and shared/dynamically linked, for all supported platforms), and sample code (we only have a Windows example so far) for the first release: https://github.com/AccessKit/accesskit/releases/download/accesskit_c-v0.1.0/accesskit_c-v0.1.0.zip

Proud to recognize the #talon hands-free computer controller as the first end user application to integrate #AccessKit!
https://accesskit.dev/talon-voice-control-application-implements-accesskit-in-latest-beta/
#accessibility #egui

Exciting news about #AccessKit: Talon (https://talonvoice.com/) is one of the first real applications to use AccessKit. In the current beta build (for Patreon supporters), the Talon app core has been ported from Qt to #Rust using the #egui toolkit, and it's now accessible with AccessKit on Windows and macOS (Linux AccessKit support is close, but waiting on a bug fix). #accessibility

Thanks to work from @nolan, #AccessKit is now integrated into the latest version of the @bevy game engine. This is the first general purpose game engine to include first party accessibility support.
https://accesskit.dev/accesskit-integration-makes-bevy-the-first-general-purpose-game-engine-with-built-in-accessibility-support/
#gameDev #indieDev #accessibility

And yes, this is something I'm exploring for #AccessKit. Once I get that project's core crates to be no-std compatible, I can look at providing a C API as static and dynamic libraries with an absolutely minimal runtime environment.

I'm thinking again about my approach to third-party Rust dependencies in #AccessKit.

On the one hand, having zero third-party dependencies in the core crates looks very attractive to some subset of users. So I already eliminated the dependency on kurbo by copying the parts of kurbo I need (with attribution). And I'm working on eliminating the dependency on parking_lot.

(to be continued)

Dramatically reducing AccessKit's memory usage
https://accesskit.dev/dramatically-reducing-accesskits-memory-usage/
#accessKit

I wonder if it would be worth it for me to go to PyCon US this year to talk to folks about making their non-web Python UIs (e.g. Kivy and Pygame-based things) accessible with #AccessKit. Of course, AccessKit would need to have Python bindings first, but I can work on that between now and April. Of course, it's too late to do a talk, but there's always the hallway track, and maybe I could apply for a community booth. I can currently afford the PyCon registration and travel expenses.

I notice that the #AccessKit Unix adapter (the AT-SPI implementation, in pure Rust, including the D-Bus implementation) adds about 1.2 MB to the binary size of a simple program, in a release build with optimization for size turned up to the max. I wonder if this is going to dissuade some developers from adopting AccessKit, and if so, what can be done about it.