I have a different philosophy and approach to using computers than most, and that affects my views on accessibility. Stapling a screenreader onto a graphical application, for example, to me seems like the wrong approach. Text-based applications are much more accessible, and these are my bread and butter. To this end, my work on accessibility involves making more information available as text, organized logically rather than spatially, and making it easier to access and manipulate that information with vision impairments (and other sorts of impairments, too).
I've found that, counter-intuitively, a fully accessible GUI program with a good GUI screen reader is easier to use than a screen-oriented terminal program with a screen reader. The trouble with the latter is that the user has to understand visual concepts like highlighting, the meaning of special characters, etc.
Of course, an application or plugin that's tailor-made for doing a particular task with speech output is better than either of those other choices -- as long as you don't have to use an application that's overall inferior (e.g. using the Emacs/W3 web browser with Emacspeak as opposed to a mainstream browser).
Poorly. I want to improve aerc in this respect. For the time being, I use a mix of my braille reader (brltty) and piping emails into vipe so I can use my vim plugin to read them.
I can understand that. I think many of us have just accepted that it has to be this way, because we're a minority and we want to have all of the advantages of using mainstream applications (economies of scale, active development, not being at an extra disadvantage compared to sighted peers, etc.).
Of course, you don't fit the profile of a "mainstream consumer" when it comes to computers. In particular, I gather that you take full advantage of the hackability of free software. So using custom TTS plugins as opposed to a clunky generic screen reader is just an extension of that overall approach to using computers.
Even 20 years ago the limitations of those options were clear to anyone who was willing to face reality. I was in denial for a while. (Note: I have limited vision, but I spent a lot of time helping blind people use Linux back then.)
Of course, Lynx and Emacs/W3 aren't the only alternatives. I think an interesting option would be a specialized browser UI based on headless Chromium.
In any case, I'm guessing Drew won't give up his free-software ideals easily, if at all. And he's a capable enough hacker that I'm sure he'll come up with a solution that works well for him.
Braille is easy, I could read it reasonably well with just a couple of days of study.
I also use VIM because it feels like the best case of voice integration or braille integration...but I have no source for how to actually do this properly. Are there good reading materials on this?
Currently I am trying to build a semantic web browser, also with the intention to filter out all legacy crap CSS that prevents interaction with the content [1] and the idea of being able to train CNNs with the content... but when it comes to code, my memory of it seems to suck so hard that I always have no clue of what I wrote the day before.
[1] still alpha as hell: https://github.com/cookiengineer/stealth
(Also a long time observer of your work here. You are one of the good guys. Stay awesome!)
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!
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.
Also, do you run brltty on a Linux text console, or in a terminal window in your Sway session?
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 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.
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. :)