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/

@Jonizulo_mstdn With your suggestion on accessibility improvements in @gnome , it might make sense to contact the developers of Newton, the #Gnome #Wayland native #accessibility project. I don't know who is the best to contact there. The blog was written by Matt Campbell, but I don't know whom to best contact.

https://blogs.gnome.org/a11y/2024/06/18/update-on-newton-the-wayland-native-accessibility-project/

#disability
#linux #accesskit

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/

#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

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/

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.

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

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/?