Skip to main content

Search

Items tagged with: 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).


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


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.


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.


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


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


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


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 (https://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