#accesskit — Public Fediverse posts

@godotengine Congratulations on landing cross-platform screen reader accessibility via #AccessKit in this release!

Congratulations to @YaLTeR and @DataTriny for getting screen reader accessibility implemented in the latest release of the niri Wayland compositor, using #AccessKit. https://github.com/YaLTeR/niri/releases/tag/v25.08

The recording of my #RustWeek talk about #AccessKit is now published. https://www.youtube.com/watch?v=OI2TzJ6Sw10

The #RustaceanStation podcast just released an interview that Luuk van der Duim did with @DataTriny and me about #AccessKit at #RustWeek: https://rustacean-station.org/episode/accesskit-with-matt-campbell-and-arnold-loubriat/

My #RustWeek conference talk about #AccessKit is coming up in about 3 hours, at 10:25 CET. That's 8:25 UTC, or 3:25 AM US Central time (my usual time zone). It will be live-streamed here: https://rustweek.org/live/wednesday/ My talk is in the main track.

I'll be giving a talk this year at #RustWeek, in Utrecht, in the Netherlands. It will be basically an updated version of the talk I gave about #AccessKit (https://accesskit.dev/) at RustConf 2023. https://rustweek.org/talks/matt/

Here's my latest update on Newton, the #Wayland-native, #Flatpak-friendly #accessibility project for the modern #FreeDesktop ecosystem, developed as part of @gnome and funded by @sovtechfund. It's not ready for production yet, but this blog post includes a demo video and links to GNOME OS and Flatpak runtime builds you can try. As a bonus, because I'm integrating #AccessKit into #GTK, GTK apps will finally have #a11y on Windows and macOS. https://blogs.gnome.org/a11y/2024/06/18/update-on-newton-the-wayland-native-accessibility-project/

Just noticed that in the latest version of the JAWS screen reader (JAWS 2023), UI Automation live regions are now announced; they weren't in JAWS 2022. Thanks #Vispero. Now I don't have to compromise on the UIA implementation in #AccessKit by using notifications where live regions should be used. #accessibility

There's a nice article out there by @jzb summarizing @matt's recent #OSSNA presentation on his work on #AccessKit and "Newton", the new #accessibility architecture for #Wayland and the future of #GNOME & #Linux for assistive technologies: https://lwn.net/Articles/971541/

The #Kivy UI framework for #Python has been completely inaccessible to screen reader users for many years. But my colleague Arnold Loubriat is working on fixing that, using #AccessKit, particularly the Python bindings that he developed. There's still a long way to go on this project, but he has posted his work in progress here: https://github.com/DataTriny/kivy/tree/accesskit-demo And here's the tracking issue: https://github.com/kivy/kivy/issues/8547

#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

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.

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.

@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.

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.

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.

@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 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.

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.

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.

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.

Just returned home from Albuquerque. I had a productive and enjoyable time at #RustConf. I'll post my talk about #AccessKit here when it's available.

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.

There's a nice article out there by @jzb summarizing @matt's recent #OSSNA presentation on his work on #AccessKit and "Newton", the new #accessibility architecture for #Wayland and the future of #GNOME & #Linux for assistive technologies: https://lwn.net/Articles/971541/

There's a nice article out there by @jzb summarizing @matt's recent #OSSNA presentation on his work on #AccessKit and "Newton", the new #accessibility architecture for #Wayland and the future of #GNOME & #Linux for assistive technologies: https://lwn.net/Articles/971541/

There's a nice article out there by @jzb summarizing @matt's recent #OSSNA presentation on his work on #AccessKit and "Newton", the new #accessibility architecture for #Wayland and the future of #GNOME & #Linux for assistive technologies: https://lwn.net/Articles/971541/

There's a nice article out there by @jzb summarizing @matt's recent #OSSNA presentation on his work on #AccessKit and "Newton", the new #accessibility architecture for #Wayland and the future of #GNOME & #Linux for assistive technologies: https://lwn.net/Articles/971541/