Notices by Matt Campbell (matt@toot.cafe), page 3

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

@nah @aral I'm removing Sonny from this thread. I don't think we need to bother him with this extended debate.

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

accesslib
libaccess
a11ylib
liba11y

None of those are particularly inspired.

@drewdevault And if people really want to keep using X with their old window manager, they could run Xwayland in rootful mode under a full-screen Wayland compositor like cage, right?

@sxpert @drewdevault I presume that if someone really wanted to put in the work, they could create a new stand-alone X server based on the modern KMS/DRM graphics stack, the same one used by Wayland compositors, using Xorg code as a starting point. I think it would be much less work, though, to write a script that starts cage and Xwayland. Then you could invoke that script as if it were a good old X server.

@sxpert If there's so little to be done, then maybe you can do such a good job at it that the distros decide to keep Xorg after all. What I've read, though, is that Xorg doesn't just work, particularly with newer hardware.

@drewdevault

@luis_in_brief @dalias @simon @danilo @maria It would be interesting to see an LLM tuned for instruction-following, particularly iterative instruction following taking prior context into account, that is specifically trained not to emulate a person, e.g. no first-person pronouns.

I'm getting tired of simplistic, indignant characterizations of generative AI like this one: https://social.ericwbailey.website/@eric/111584809768617532 "a spicy autocomplete powered by theft that melts the environment to amplify racism and periodically, arbitrarily lie"

It's a tool like any other; it can be used for good as well as bad. Yes, the copyright issue is real, but we can presumably overcome it by using models whose developers are more scrupulous about their sources of training data, not throwing out the whole thing.

I'll mention again a more balanced take from @danilo that I posted the other day: https://redeem-tomorrow.com/the-average-ai-criticism-has-gotten-lazy-and-thats-dangerous

I also like @simon's writing on generative AI.

I like this post from @danilo which addresses some lazy criticisms of generative AI while also discussing several legitimate criticisms: https://redeem-tomorrow.com/the-average-ai-criticism-has-gotten-lazy-and-thats-dangerous

If the only legitimate use of that setting is for that specific Vietnamese input utility, then I have a proposal for a different solution to that specific problem, which eliminates the setting, since it's too easy to turn off the setting without knowing what one is doing and break other things. But I want to collect more information about possible other uses of that setting before proposing my own solution.

Question for NVDA users: In the keyboard section of settings, there's a checkbox called "Handle keys from other applications". This setting is enabled by default. If it's disabled, it prevents remote access tools from working well with NVDA on the remote target machine. But this isn't clear to someone just looking through the settings. The setting was added due to an issue with a specific Vietnamese input utility. Does anyone have any other reason to turn it off?

Thanks to my foray into GNOME history yesterday, I'm thinking about this NVDA setting in light of a classic article by a GNOME developer on the cost of preferences: https://ometer.com/preferences.html

Came across this article on the decline of usability which, among other things, puts GNOME 3 in the same category as the notorious Windows 8. https://datagubbe.se/usab2/

I know that classic Mac/Windows conventions like menu bars and title bars aren't sacred forever. But this article does make a convincing case that the industry at large, including GNOME, has gone backward. And, at least for me, that's uncomfortable to contemplate.

Yesterday I boosted someone else's announcement of my post on the new GNOME accessibility blog, but apparently some folks couldn't find the link in that toot, so here it is again: https://blogs.gnome.org/a11y/2023/10/27/a-new-accessibility-architecture-for-modern-free-desktops/

Also wanted to add: I'm glad to be getting back to work on accessibility on desktop Linux, after ~20 years away. Hopefully with the experience I've gained in the meantime, my efforts now will be more effective.

@simon An LLM would certainly be more knowledgeable; the only question is whether an LLM-based agent can be coaxed into forwarding the issue to someone who can do something.

Disclaimer: I'm thinking out loud here, not announcing that I have the definitive answer.

On Windows, what we often call the self-voicing approach is made more practical by the fact that the major third-party screen readers offer APIs for sending text strings to the screen reader to be spoken and/or shown on a Braille display, so applications that take this approach don't have to use their own text-to-speech engine. None of the platform-provided screen readers offer something like this though, even on Windows.

Someone looking at GUI accessibility without knowledge of the current solutions would probably conclude that the obvious way to make a GUI accessible is for the GUI toolkit itself to support alternative input and output methods. For example, the GUI toolkit could directly render the text to be spoken or shown on a Braille display. And in fact, for the most part, the games that have been made accessible to blind people have implemented accessibility this way.