Update on Newton, the Wayland-native accessibility stack I'm developing for GNOME and (eventually) other desktops: I have an end-to-end prototype, using a Wayland protocol extension for the connection between applications/toolkits and the compositor, and D-Bus for the AT-to-compositor interface. I have an experimental branch of Orca with basic focus announcement and mouse review working. 1/?
Question for anyone working with Rust on desktop Linux: Is there a quick and easy way to take a Rust GUI application that natively supports Wayland builds as a single, self-contained binary, and turn it into a fully sandboxed Flatpak app?
@aral GNOME folks are well aware of the problems with Orca on Wayland, and actively working to fix them. There's even funding for this work, thanks to the Sovereign Tech Fund. I'm personally working on a new Wayland-native accessibility stack that aims to eventually replace AT-SPI and support sandboxed apps, but there are also efforts to fix problems in the existing stack in the short term. cc @sonny
It's clear that the name of my AccessKit project (https://github.com/AccessKit/accesskit) is a recurring stumbling block. When mentioned without appropriate context, it carries the connotations of being an Apple API. Plus, there's actually another AccessKit, which ranks higher in a DuckDuckGo search: https://accesskit.media/
So I'm actually thinking about renaming my AccessKit. The best names I can come up with are:
Additional context for my followers who might not be in the know: AudioEye is an accessibility overlay, a type of product that claims to give websites a generic solution to accessibility with a simple JavaScript snippet. These scams have been going for years now. In my opinion, they're more about cashing in on the fear of lawsuits than actually serving disabled users.
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
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
Software developer, formerly at Microsoft, now leader of the AccessKit open-source project (https://accesskit.dev/) and cofounder of Pneuma Solutions (https://pneumasolutions.com/). My current favorite programming language is Rust, but I don't want to make that part of my identity.Music lover. Karaoke singer. Science fiction fan. Visually impaired (legally blind). Secular humanist