Even with the aid of sight, I don't read an entire codebase at once. I follow the logic, a few lines at a time, as it moves through the parts I'm interested in. I use grep to find the things I ought to read. With this approach, I build a mental model of the codebase quickly, with lots of blanks - but with detail in the areas I'm focusing on.

As for how to actually rig up braille readers on Linux, check out BRLTTY. It's pretty straightforward. I was working on an Alpine Linux spin which was more accessible out of the box, but I got discouraged by various circumstances and shelved it.

I think your use of the term "braille reader" might be causing some confusion. I know you use brltty. But do you use its text-to-speech output, or do you use a refreshable braille device that moves little pins up and down to form braille cells? If the former, I'd suggest referring to brltty as a screen reader.

Also, do you run brltty on a Linux text console, or in a terminal window in your Sway session?

I use a refreshable braille display. I use it mainly on the Linux console, but I've been thinking about rigging something up for use with Sway.

Wow, I underestimated your seriousness about adapting to alternate output methods. Did you have to buy that braille display at your own expense? As I'm sure you know, they're expensive. How recently did you start learning braille? Has it been a challenge for you to learn to read it with your fingers?

I bought a cheap used one off of eBay, it wasn't too expensive - a few hundred bucks. I know that nicer ones can get up there, though. Learning braille was an unusual challenge, but I didn't find it especially difficult. It only took a couple of days to become reasonably proficient with it. The braille display I ended up with is pretty nice despite its price tag, it has a good finger-feel to it and has a nice set of basic features.

The most difficult thing for me would be learning advanced levels of braille, which involves memorizing shortened forms of many words, but I reckon I can get away with just using long-form for a good long while.

> I also use VIM because it feels like the best case of voice integration or braille integration

Check out Emacsspeak: http://emacspeak.sourceforge.net/

It’s written by T.V. Raman, a blind engineer at Google by way of Cornell.

Among other things, with it you can just use the built-in Emacs browser!

Would you be willing to chat privately with a colleague of mine going through a similar lost of sight transition?

(BTW, stealth sounds awesome!)

Thank you :3 It’s still a ton of work. I heavily underestimated the networking and parsing part...and had to invent a testrunner that can test networking implementations with known buggy situations (e.g. simulate fragments like on 2g slow mobile situations).

I totally switched my workflow to Test Driven Development due to the last 6 months parsing CSS and http1.1 responses.

It’s amazing how much server infrastructure violates w3c specs and recommendations. Something like partial content (206) is mindblowingly crappily implemented on servers these days when it comes to keep alive sockets and multiple range requests. Some servers reply only with chunked encodings, even for frames with less than 256 bytes (looking at you, cloudflare dns), some only send back a single stream...some just send back ranges without headers...

And I only support http1.1 as of now, because http2 and 3 are both kinda undebuggable and there’s no reference-class testsuite to test against implementations.

That sounds brutal!

Still, it seems like a very worthwhile project. I'm fed up with modern browsers myself (the "megabar" on Firefox 75 is, somehow, the last straw for me.)

I'm going to keep an eye on Stealth because it sounds like the perfect browser/proxy engine for an experimental UI I'm working on.

Cheers! Good work and good luck. :)