Skip to main content

Search

Items tagged with: 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. blogs.gnome.org/a11y/2024/06/1โ€ฆ


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: lwn.net/Articles/971541/


I just joined the #Robius matrix chat, and gave a link to my toot above.

I created an issue some time ago in the #Makepad tracker about #a11y:

github.com/makepad/makepad/issโ€ฆ

Who knows.. maybe the wheel need not be reinvented again, right? And they are open to #AccessKit.

Btw, thank you for your talk yesterday. I really liked it, it was a great presentation.


Hi @matt ๐Ÿ‘‹

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?

github.com/project-robius


Just saw that the Zed code editor (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: github.com/DataTriny/kivy/treeโ€ฆ And here's the tracking issue: github.com/kivy/kivy/issues/85โ€ฆ


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


I should also thank everyone who has worked on PyO3 (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. 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 can't stop wondering if, to truly meet my goals for the #AccessKit project (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/?


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! 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: github.com/AccessKit/accesskitโ€ฆ


Exciting news about #AccessKit: Talon (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


Excited to announce that my recent work integrating #AccessKit into #Bevy was recently merged, making accessibility (mostly) on by default in the upcoming 0.10 release due out soon if not today.

The one exception is Linux, where it is feature-gated pending reduction in dependency size and integration with non-experimental screen readers and forks.

I think this may make Bevy the first general-purpose game engine with accessibility in its core (I.e. not a bolted-on optional plugin or a series of partial solutions. In any case, it's the only game engine with accessibility features that I can use as a blind developer, though #Godot also seems to be making strides in this direction as well.


I think one of the first non-Rust GUI toolkits that I want to see #AccessKit integrated into is Tk. It's still the de-facto default GUI toolkit for Python, and I just came across a Python IDE designed for beginners that uses Tk. In the meantime, I hope that IDE isn't being used in intro programming classes.


I'm willing to pay up to $10,000 (USD), to whomever I need to pay, to solve the #GNOME AT keyboard input handling problem once and for all. Currently, toolkits implementing AT-SPI have to pass all keyboard events to the AT-SPI registry, then wait for a response on whether the event should be processed as usual. No other platform does something like this, and this unique platform-specific requirement is a major complication for #AccessKit. I want to get this fixed. #accessibility


Encouraging to see the dream of #AccessKit (github.com/AccessKit/accesskit) becoming a reality. I just finished the first iteration of macOS support for text edit controls, and the work I did in egui, which I had tested with the AccessKit Windows adapter, only required a one-line fix to be fully functional on macOS. And even that change wasn't exactly Mac-specific, just something that didn't happen to be needed on Windows. Also, integrations in other GUI toolkits are in the works. #accessibility

โ‡ง