|
9 posts total
Hot take: Websites or publishing platforms including estimated reading time in blog posts is ableist. It says, "We estimate that a normal person reads at this speed, and if you don't, we're going to remind you at the top of every post that you're not normal." For users who need or want an estimate of reading time, their user agent (e.g. the browser or a browser extension) should do that, in a way that's tailored to them.  @matt Awesome! This is incredibly needed! Thank you! Any thoughts on when the voice stop hurting, though? I think if I had to listen to that thing all day my ears would start bleeding pretty quickly :/ I understand that is probably not your area, but maybe you have some insight into what work is being done there? My #rustconf talk about @accesskit is posted! https://www.youtube.com/watch?v=LRBKb6McgqA 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.  @matt Oh nice. IIRC they were previously staying silent about whether it would be proprietary. It looks like they've decided on making all the code open and selling subscriptions for hosting the collaboration features built into the editor. The server part is licensed AGPL. I'm excited to announce that egui (https://github.com/emilk/egui) is now the first pure-Rust GUI toolkit to implement platform accessibility APIs (most mature on Windows, with macOS catching up), via AccessKit (https://github.com/AccessKit/accesskit). This was just merged in egui's master branch. New versions of egui crates should be published to crates.io soon. Thanks to the Google Fonts team for funding both the development of AccessKit and the integration in egui. And before anyone asks, a Linux/Unix backend for AccessKit, with a pure-Rust implementation of AT-SPI, is under development, but not ready yet. Thanks @raph for an informative talk on high-performance Rust UI. Here's a direct link to the part on AccessKit, including a demo using VoiceOver on Mac: https://www.youtube.com/watch?v=zVUTZlNCb8U&t=3271 Yes, there's a bug in the calculation of bounding boxes that caused the VoiceOver highlight to be wrong; I think it's a DPI issue. For anyone who missed it, @raph will be doing a talk about high-performance Rust UIs on Twitch tomorrow at 8 AM Pacific. https://www.twitch.tv/raphlinus/ And, most exciting for many of my followers, he will be demoing some of the work I've been doing on making GUI accessibility more approachable for toolkit developers through AccessKit (https://github.com/AccessKit/accesskit). #accessibility question: I've got a demo program for a GUI toolkit, which has a text field, a slider, a button, and some static text. The static text incorporates the values of the text field and slider, and the button increments the value of the slider. Should I make the static text a live region, such that it gets announced whenever you edit the text field or adjust the slider? Or only fire off an announcement when you press the button that increments the slider value? |
Gregory's Server
Yes, my own open-source project's website currently has this (mis)feature. We got it automatically as part of the theme we chose. But I'm planning to get rid of it now that I've thought about it.
@matt why not indicate the number of words instead?