Me: All general-purpose personal computers should be fully open and hackable. Don't dumb them down; give the users full power to do whatever they want.
Also me: Tech support would be easier if all user machines were as locked down as the iPad. Windows gives users too much rope to hang themselves.
The second thought occurs to me sometimes when handling a tech support case where a Windows user did something that, at least from my point of view as the developer, seems self-evidently stupid.
OK, I might as well share what the user did, as long as I don't share their name. They meant to copy an application shortcut (.lnk) file to the Startup folder, but they copied the executable instead. Then when the executable ran, it showed an error about a missing DLL, because most real-world Windows executables don't work when copied outside their installation directory. Maybe it's unreasonable to expect the user to know that though.
Now, this particular application registers itself to run on startup, via the standard registry key for that purpose, on installation. We still haven't figured out why that's not working for this user, which is the only reason they bothered to try copying the application to the Startup folder. Probably some obscure power-user Windows setting, or maybe third-party add-on, is to blame.
Question: Has anyone run into any real accessibility challenges in a work or (more likely) educational environment because Linux GUI apps aren't accessible with ChromeVox on Chrome OS? Thinking about a potential future project that could build on my current Wayland accessibility work. Wondering if it's really worthwhile though.
It's too bad that a full hardware-based memory safety solution like CHERI (https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/) didn't reach production in time to be included in Microsoft's Copilot Plus PCs, and other new hardware that's riding the AI hype train. As it is, if something like CHERI ever does catch on, we're going to have a second wave of hardware obsolescence when we could have had just one. Yes, CHERI is an academic project, but Microsoft and other industry players could have put more resources on it.
I just had an idea: It would probably be feasible to implement a way to install and run any Flatpak-packaged desktop Linux app on Windows and macOS inside a micro-VM, using a virtual machine host like Firecracker, or more likely, Firecracker's progenitor crosvm, which was designed for running an arbitrary Linux userland on Chrome OS. I believe crosvm can even run on Windows, using the Windows Hypervisor Platform (also called WHPX).
@matt currently at work I have to use windows and there are some nice Linux apps that I definitely miss. It would be great to easily run flatpak apps cross platform.
I recorded a quick demo of the current state of the Wayland-native accessibility stack I'm developing for @gnome (and eventually other free desktops), code-named Newton. In the demo, I run the GNOME Podcasts app on the Newton accessibility stack, using my GTK branch that integrates AccessKit. So in principle, the same app should also work on Windows, and soon, macOS. The demo was featured in the latest edition of This Week in GNOME: https://thisweek.gnome.org/posts/2024/05/twig-148/ This work is funded by @sovtechfund.
@JoSuus AT-SPI kind of works on Wayland. There are problems though stemming from the fact that there's no connection between the AT-SPI accessibility tree and the actual Wayland surface. For example, Orca can't tell what's under the mouse pointer with AT-SPI on Wayland. That already works in the Newton prototype, though I didn't cover it in this demo. Also, AT-SPI is incompatible with strong sandboxing. I hope to demo a fully sandboxed Flatpak app with Newton soon.
@JoSuus Also, with AT-SPI, Orca can't observe keyboard input on Wayland unless you use a toolkit that supports the legacy AT-SPI method of key snooping, which GTK 4 does not, because that old method has various problems, like the requirement of an IPC round trip for every keystroke. I don't know if the Newton prototype's current solution to that problem will make it to production; there have been other efforts to solve that problem on Wayland.
Regarding my last boost, about both light and dark mode being necessary, one thing that I think would be made feasible by my current Wayland accessibility work, with some help from the compositor, would be re-rendering the whole visual UI using the contents of the accessibility tree, continuously in real time. I don't think the current accessibility APIs are up to that, because of IPC overhead.
All the positive coverage of PyCon US that's coming across my timeline makes me wish I was there. And, for that matter, that I used Python more these days. Mind you, my experience of the Rust community has also been good, including RustConf last year. But PyCon sounds like a lot of fun.
To follow up on the post from @fedora that I just boosted (https://fosstodon.org/@fedora/112450335722898487), I'd like to thank @sovtechfund for funding my work on @gnome accessibility, and acknowledge that they're also funding other, more immediate work on GNOME accessibility, including the Spiel speech framework (https://project-spiel.org/) and a variety of improvements to the Orca screen reader. My project might be getting the most attention, but it's not the only important work happening in this area.
About my last boost (https://mastodon.social/@verge/112406416876801156): It sounds to me like the problems with the new Sonos app go beyond accessibility. I suspect a poorly managed rewrite. Given that the new version is such a step backward from the previous working app, I wonder if a rewrite was necessary in the first place. But I know our industry isn't good at maintaining a complex, long-lived codebase. We'd rather do something new and, we assume, better.
Is there any currently maintained Android screen reader that supports app-specific scripting? And if so, do any blind Android users actually use it? Still thinking about the problem of apps like the Sonos app regressing in accessibility (see my earlier thread), and how we might take matters into our own hands as we have often done and sometimes still do on Windows. Of course, the dominant mobile platform in the blind community doesn't allow this at all.
@TheQuinbox@matt Oh. That's crap. Surprised we don't have a term for this scenario of "all was great, woke up one morning, and an update took it all away." Actually, that kinda sounds like a Blues song.
@matt This doesn't work when developers use libraries like styled components, which don't rely on IDs and class names at all. There may be ids and class names, but they're an internal implementation detail and have no guarantee of stability.
@matt I'm getting more and more convinced that slapping an AI-based accessibility overlay is eventually going to be the solution, and it's going to happen basically before anything else. We wont turn around the screen-reading world in 5 years, and I wouldn't be surprised if we got working overlays by then.
@matt Unless you were proposing reading it as an artifact of its time in a more historical context. In that sense, it sounds like it would definitely be interesting. And, I could simply be wrong on this particular title.
@jscholes No, I was thinking of reading it to look for things I can practically apply. The fact that it's been so long since I even remembered binary search makes me think that I've spent too long immersed in the incidental complexity of real-world software development, especially high-level product development, and that I should get back to the fundamentals.
OK, that was the second time I boosted a post about the "Leaving Rust gamedev after 3 years" article. But that last boosted post called out how the article is really largely about hype cycles and tech zealotry. I read the article the first time, and I think it is leading me to moderate my enthusiasm for Rust and be careful about how I hype my own Rust-based library. (Though no, there is absolutely no possibility that I'm moving away from Rust in AccessKit.)