matt

@matt@toot.cafe

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

This profile is from a federated server and may be incomplete. Browse more on the original instance.

glyph, (edited ) to random
@glyph@mastodon.social avatar
matt,

@glyph I think the last time I called it was when it was a built-in in Python 2.

nick, to random
@nick@hkc.social avatar

@jcsteh Hey man, hope you're well...

Interesting Firefox behavior in 126. Things that formerly exposed to the screen reader as "tabs" are now Links, as things that used to show as "menu items" are now "buttons". Nothing in release notes. Intended behavior?

matt,

@jcsteh @nick If you were to go back to technically violating the spec on this, while making spec-violating sites more accessible in practice, I don't thinka nyone could reasonably blame you. Aside from the failed XML-ization of HTML, browsers have always gone out of their way to do what the author meant even if the author didn't comply with the letter of the spec. That approach should go double for accessibility.

matt,

@jcsteh @nick If you were to go back to technically violating the spec on this, while making spec-violating sites more accessible in practice, I don't think anyone could reasonably blame you. Aside from the failed XML-ization of HTML, browsers have always gone out of their way to do what the author meant even if the author didn't comply with the letter of the spec. That approach should go double for accessibility.

matt,

@jcsteh @nick I've now discarded a couple of possible replies. The fact that some stupid spec requirement can stop you from doing what's best for actual accessibility in practice, because failing web platform tests would make you look bad, makes me angry. I can't blame you for bowing to that pressure, but still...

matt,

@jcsteh @nick Sure, but the first rule of AT is that you make the best of the half-broken crap that the application or content author implemented, because we all know that very few will go to the trouble to get it exactly right.

matt,

@jcsteh @nick Good luck getting that requirement removed.

matt,

@jcsteh OK, fair enough.

@nick

weirdwriter, to microsoft

GUI Tool To Removes Ads From Various Places Around Windows 11 https://github.com/xM4ddy/OFGB #Microsoft #Windows #OpenSource

matt,

@ljwrites @KekunPlazas @weirdwriter Hi all. Thankfully, I'm not working alone on GNOME accessibility. In fact, in addition to funding my own work on an overhauled accessibility stack, Sovereign Tech Fund is also funding some more short-term work by other developers, which is already starting to land. And lest you get the wrong idea, this other work is (at least most of it) not just a stopgap until my work is ready; it's all equally important and necessary.

matt,

@ljwrites @KekunPlazas @weirdwriter The fact that you heard about my project in particular means that I already got enough publicity. Thanks though.

glyph, to random
@glyph@mastodon.social avatar
matt,

@glyph I could probably write an ad-hoc solution in pure Python using ctypes and comtypes, writing my own API definitions as needed, in an hour or two. Or I could whip up something in Rust, using the windows crate and PyO3, requiring a small extension module (a few hundred KB tops in a release build). Which would you prefer?

matt,

@glyph Well it's not quite one function. You have to instantiate the class, using some function that takes the class name as a string. Then you have to call the GetTimeZone function, which returns a string. And in both cases, "string" means the WinRT HSTRING type, which is a refcounted string. I hope @tef's solution works for you, because rolling my own using ctypes and comtypes might be a little more complicated than I thought.

danirabbit, to random
@danirabbit@mastodon.online avatar

Something I’ve never heard someone who works with accessibility say, but have heard a number of times from people who don’t work with accessibility: “AI is gonna be so valuable for a11y”

matt,

@danirabbit I've worked in accessibility for over 20 years, I'm visually impaired myself, and in my more pessimistic moments, I've thought that AI that actually works would be our only hope of accessibility that actually scales to the long tail of apps, sites, etc., without us having to beg every single developer to put time into making their stuff accessible.

matt,

@danirabbit I appreciate your response. But honestly, I can also see the point of view of developers who ignore accessibility or even let it regress. Everyone has limited resources, and I guess we're a small enough minority that those developers are doing the rational thing from a purely economic perspective. Maybe we need better regulations. But still, a technological solution that could possibly mitigate many instances of the problem at once is appealing.

matt,

@weirdwriter Your mention of @danirabbit got mangled somehow, so I don't think she was actually included in the reply.

bryansmart, to random

For all of the blind people who just lost access to the Sonos app, and everyone else who’s accessibility done gone away, I dedicate The Accessibility Blues.

matt,

@bryansmart So how much of that, if any, was AI-generated?

matt, to random

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.

matt,

I don't even use Sonos myself. But I've been reading a lot of discussion about the accessibility regression on my timeline, so I'm curious about it.

matt, to random

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.

matt,

OK, I should say, the dominant mobile platform in the English-speaking, developed-world blind community. And of course, I mean iOS. Now I'm tempted to switch back to Android.

matt, to random

Context on my last boost (https://dragonscave.space/@jscholes/112406794436648906) for my followers who aren't plugged into the blind community: Sonos recently released an update to their mobile app that makes it way less usable with VoiceOver on iOS, and presumably TalkBack on Android as well. @jscholes has insightfully connected this to the genericization of UI development, and this post in particular: https://www.baldurbjarnason.com/2024/react-electron-llms-labour-arbitrage/

matt,

I do wonder what we can do about this. I don't like spreading hopelessness. But we do have to confront the problem.

matt,

The best idea I have so far is this: Win32 and classic hand-coded web user interfaces used to leak implementation details, including class names and IDs (numeric control IDs in Win32 dialogs, string IDs for HTML elements). This wasn't done for the sake of accessibility, but developers of screen reader scripts/add-ons made the most of these things to work around the app developer's indifference toward accessibility, especially for Win32.

matt,

So what if we could get the current generation of component frameworks to expose IDs and maybe even class names (or equivalent) as well, in properties that can be accessed by assistive technologies? UI Automation has the ClassName and AutomationId properties. I don't know if Android has anything useful here. And of course, all of this would be useless on iOS unless Apple does something very out of character, like adding scripting to iOS VoiceOver.

matt,

SO yes, my conclusion is that we, meaning assistive technology developers and to some extent users, will always have to work around app developers' indifference toward accessibility. Maybe that just comes with being an economically insignificant minority. Maybe we can at least get better tools for doing that.

talon, to random
@talon@dragonscave.space avatar

Hey if Sonos can just up and screw their UI then I can just up and decide to never use them for future speakers. Time to check the resale value of this garbage in case they can't fix the UI accessibility like yesterday.

matt,

@jscholes @simon @talon I finally looked at the Android app. (I'm not a Sonos user, but I'm curious about this whole disaster.) It's Flutter, which is the other major cross-platform mobile UI toolkit. That puts the app at a further disadvantage, because Flutter renders its own widgets and has to implement its own accessibility for those widgets, rather than wrapping native ones.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • tester
  • everett
  • magazineikmin
  • thenastyranch
  • Youngstown
  • Durango
  • rosin
  • slotface
  • InstantRegret
  • mdbf
  • PowerRangers
  • kavyap
  • tsrsr
  • DreamBathrooms
  • Leos
  • ngwrru68w68
  • hgfsjryuu7
  • cubers
  • GTA5RPClips
  • khanakhh
  • vwfavf
  • ethstaker
  • osvaldo12
  • cisconetworking
  • normalnudes
  • tacticalgear
  • modclub
  • anitta
  • All magazines