> Honestly if you ever observe a blind person using computers you'd impressed how they can listen to audio at unimaginable speeds.

Even better, fire up Orca (or whatever screenreader application your OS comes with) yourself and try to use your computer while shutting your eyes, kind of eye-opening (no pun intended) what kind of experience these sort of users typically get. And also, you quickly start to understand why they set the speech rate for their voice synthesizer to be so fast, it's almost unbearable navigating applications (and particularly lists) otherwise.

▲

jchw 10 hours ago | parent | next [-]

When I was at Google, I'd periodically test our (internal-only) app with Chromevox with the display off. It's not that it sounded like it would be easy, but it really is a challenge, and I can only imagine the muscle memory built up over time of trying to work around accessibility bugs and strange behaviors.

Unfortunately it seems impossible to get all that much funding for accessibility work :/ I wonder what ever happened to the Newton accessibility bus intended to supplement Wayland...

▲

kridsdale1 8 hours ago | parent | next [-]

I’ve worked at Apple Facebook and Google. Apple was the only one that made a11y bugs and a face to face consultation with a blind developer to show you how your app sucked, mandatory before you could launch.

▲

embedding-shape 8 hours ago | parent | prev | next [-]

> I wonder what ever happened to the Newton accessibility bus intended to supplement Wayland...

Hm, never heard about it, but now I'm wondering too. I just finished implementing proper accessibility support for my native app toolkit for Linux, macOS and Windows, but only done it for X11 so far, I was just gonna get started with Wayland. What is the accessibility story on Wayland, couldn't people rely on the same protocols as with X11? That was my impression, but haven't really dig into yet.

	▲	RobMurray 4 hours ago \| parent [-]
		It's still AT-SPI for wayland, the main difference is how screen readers grab keyboard input events.[0] I don't think there is a big difference from a toolkit point of view. I don't personally have experience with Wayland because most blind people recommend Mate as being the most accessible desktop still. Thanks for considering a11y for your toolkit - it really makes a difference to those of us who are disabled. Are you implementing a11y separately for each platform? If you use accesskit[1] you only have to implement it once for all platforms. I recently vibe coded accessibility for the Swell toolkit[2] used by Reaper. I have a branch using accesskit and a branch implementing at-spi. Accesskit made things a lot easier and more performant. Let me know if you would like a screen reader user to help with testing your toolkit. [0] https://lwn.net/Articles/1025127/ [1] https://github.com/AccessKit/accesskit [2] https://github.com/RDMurray/WDL/tree/accesskit and my fork of accesskit with some features and fixes for unix: https://github.com/RDMurray/accesskit/tree/swell-fixes

▲

miki123211 8 hours ago | parent | prev [-]

The muscle memory build-up is definitely real.

There are apps I use semi-regularly that less-experienced screen reader users thought were inaccessible, and I couldn't even explain what they were doing wrong from memory. The ways of working around accessibility issues are just so ingrained in me that all I can usually remember is "yeah I did this somehow, but it was six months ago and I have absolutely no idea which specific tricks I needed for this one."

▲

seviu 10 hours ago | parent | prev | next [-]

That time my Mac display broke and I had to log in taught me much about how important learning accessibility is even for non blind people.

▲

isityettime 10 hours ago | parent | prev [-]

> you quickly start to understand why they set the speech rate for their voice synthesizer to be so fast, it's almost unbearable navigating applications (and particularly lists) otherwise.

I imagine that for coding it also helps deal with the fundamental problem of an ephemeral stream rather than a persistent document that you can navigate visually in multiple dimensions. Working memory is limited, and getting more text in in a short period of time probably helps you work within that better. I also imagine that working with text via audio all the time gradually stretches and improves memory.

	▲	miki123211 8 hours ago \| parent [-]
		It's not the ephemeral stream that's the problem, it's the limited bandwidth. You can show a lot more info on a screen than you can transmit through speech in a short period of time. That doesn't mean you read faster than you listen, just that sighted people essentially use their eyeballs as an "input device" to decide what information to look at. If there's an object on the screen that you want to examine but that you don't need to click, you can just "navigate to it" with your eyeballs, without ever touching a mouse or keyboard. We don't have that luxury. This means we need a much more efficient system for navigating what's on the screen, but that only gets you so far. Eventually, the easiest way to deal with this problem is just to increase the bandwidth of your channel, and you do that by increasing the speech rate.