Post B51J2EzsJL34me7Y6y by matt@toot.cafe
(DIR) More posts by matt@toot.cafe
(DIR) Post #B51J2EzsJL34me7Y6y by matt@toot.cafe
0 likes, 0 repeats
There's an article currently on Hacker News about Microsoft's lack of a coherent GUI strategy over the decades. https://www.jsnover.com/blog/2026/03/13/microsoft-hasnt-had-a-coherent-gui-strategy-since-petzold/ The article said that WPF was good technology. I couldn't let that go unchallenged. I remember the bad performance that my brother suffered running a WPF app in 2010-2011 on an average 2008 laptop, because WPF's bet on GPU acceleration turned out to remain way ahead of average hardware. More in this HN comment, which sparked a thread: https://news.ycombinator.com/item?id=47656224
(DIR) Post #B51J2FE3ScOJUcksDI by matt@toot.cafe
0 likes, 0 repeats
Someone on that HN thread pointed out that Evernote ditched WPF in 2010. They couldn't find the original blog post and instead linked to a post that criticized Evernote for losing patience with .NET. https://www.edandersen.com/p/evernote-has-no-patience-drops-wpf-over-fixed-issues But I can't help but miss that earlier time when at least a few companies, outside of indie Mac apps, *cared* about desktop software performance. Just look at the care for performance across a broad range of hardware in that quoted announcement.But then, was it accessible?
(DIR) Post #B51J2FQSiUJe76YmYK by matt@toot.cafe
0 likes, 0 repeats
I do remember that the original Spotify desktop app for Windows, before they switched completely to web tech sometime in the 2010s, was also developed with the kind of "handmade" UI that some of us like to romanticize, presumably driven by caring about both performance and a distinctive look... and it was completely inaccessible to blind users.Enough looking back though. The current Rust GUI ecosystem, including AccessKit, is working on achieving efficiency *and* accessibility together.
(DIR) Post #B51J2Fh7iXdwwmM5WS by neal@social.gompa.me
0 likes, 0 repeats
@matt The upside around web tech for accessibility also isn't a given either. It's still dependent on how the UI is made, what stack is used, and how the presentation model works. I remember that SPAs for a long time were basically unusable. And websites with infinite scroll *still* are bad with assistive technology.
(DIR) Post #B51J2Fr37daDRZ00zg by matt@toot.cafe
0 likes, 0 repeats
@neal True. But the floor for completely custom toolkits is *nothing*. To get that bad with web tech, you have to go out of your way to render your own UI using a canvas element.
(DIR) Post #B51J2G0yWjWTwLdwSu by neal@social.gompa.me
0 likes, 0 repeats
@matt Sure, but standard native toolkits *do* have tagging and labeling. Whether the tagging and labeling is good is dependent on the app developer.The answer isn't to make every single app ship Chromium or WebKit just to show the UI, it's to raise the floor for system UI technologies. Qt has made great strides as a cross-platform native UI toolkit, as an example.
(DIR) Post #B51J2GBxrsJUUQmiau by matt@toot.cafe
0 likes, 0 repeats
@neal Yeah, you're right.
(DIR) Post #B51J2GJ3RVz6qQ6Ne4 by neal@social.gompa.me
0 likes, 0 repeats
@matt That being said, what grinds my gears is that there are toolkits that flat-out consider assistive technology support as "out of scope". Dear imGui is thankfully no longer one of those, but for a long time it was... And it still has no API or internal support for it at all.
(DIR) Post #B51J2GRYvsn3Go5AuG by matt@toot.cafe
0 likes, 0 repeats
@neal What changed with Dear ImGui?
(DIR) Post #B51J2GYeVWSfcnOpxQ by neal@social.gompa.me
0 likes, 0 repeats
@matt I'm not sure. At least the latest GitHub issue filed asking about it was a lot more positive about the idea of supporting it: https://github.com/ocornut/imgui/issues/8022The previous one before that was "no AccessKit because Rust": https://github.com/ocornut/imgui/issues/5833And before that was only a brief mention of "being used out of its initial scope": https://github.com/ocornut/imgui/issues/4122But I remember being told at some point in 2020-ish that it wasn't something in the cards because it was intended to be "lightweight".
(DIR) Post #B51J2GjHryy69mNKXA by matt@toot.cafe
0 likes, 1 repeats
@neal I've sometimes second-guessed my original decision to write AccessKit in Rust. If I had written it in C or C++, maybe it would be more accepted by some of these GUI toolkits. But then, I believe the project wouldn't actually have gotten as far as it has if I hadn't chosen Rust. At least we're going out of our way to provide convenient C bindings (thanks mostly to the other main developer of AccessKit, Arnold Loubriat).
(DIR) Post #B51J2IAGXA8ubk0ODw by matt@toot.cafe
0 likes, 0 repeats
@neal I mean, has someone started implementing platform accessibility APIs for that toolkit, or has there been some other gesture in the direction of supporting accessibility?