Can you elaborate how an user interface based on conversation is even remotely as efficient as a keyboard-operated screen reader? With a screen reader I can get information out of a web page much quicker than the time it takes me to think how to ”ask” for it. The only advantage with this approach I could see (assuming there would be no hallucinating etc.) is that AI can extract things out of an inaccessible / unfamiliar interface. However, in all other respects this approach would effectively lock blind people to using only the capabilities the AI is able to do. As a blind software developer this idea of a supposedly viable user interface sounds patronising more than anything.
Beets is what got me into MusicBrainz. It's an incredible resource. To be fair it's not the easiest of things to get started with and the usability could be better (release drafts, anyone?) but it's efficient once you get the hang of it.
If you're using Navidrome or similar to stream your music then check out beets-alternatives [0]. It lets you sync (and optionally convert) your library or a subset of it to another location, in my case my music storage mounted with Rclone. It's especially useful if you need to have a different naming structure in your target directory for whatever reason. I like to keep each disc of a multi-disc album in in its own subdirectory but most streaming servers seem to prefer all tracks of an album to be in the same directory. With Beets-alternatives I can have a different naming structure for each collection vs. having to rename my primary collection to suit whatever streaming server I happen to be using.
WSL 2 is one of the biggest reasons I'm able to be productive as a blind software developer. With it I'm able to enjoy the best desktop screen reader accessibility (Windows and NVDA) as well as the best developer tools (Linux). I hate Microsoft's AI and ads force-feeding as much as anyone else but trust me, you'd do the same if you were in my shoes. Screen reader accessibility on Mac Os is stagnating even faster than the os itself and even though Linux / Gnome accessibility is being worked on, it's still ready only for enthusiasts who don't mind their systems being in a constant state of somewhat broken, as illustrated by this series of blog posts from just a few weeks ago: https://fireborn.mataroa.blog/blog/i-want-to-love-linux-it-d...
I stand corrected. I'd still rather have my own personal handle that I could point to any given Mastodon account (kind of like how email aliases work) but it's absolutely better than nothing.
That is true, yes. But then there's the fact that my identity is tied to that instance. All of my followers would have to go through the trouble of refollowing me on another instance, and that is only if I'm able to tell them that the instance I'm currently on is about to go bye-bye.
That looks nice. Let's get back to this once any of those services has reached the kind of maturity that a non-techie is willing to sign up and start building their network. I have no idea what needs to happen for that to become the reality, though.
> Regular social media platforms like Facebook have a single point of failure. If their servers go down, your content goes down with it.
While I agree with the principle of this argument, I think it's far more likely that any of the publicly available Mastodon instances goes boom long before Twitter does. My different kinds of social media activities might be spread across the fediverse, but all of my toots are only on one point of failure, and technically in significantly more incompetent hands than on Twitter.
I'm not disagreeing with this article per se – I want decentralized social media to succeed as much as everyone else – but it's much too brittle and technically minded for the people I mostly like to hang out with, i.e. non-techies.
Blind since birth full stack software developer here. I might not be able to relate to your situation completely but here are some of my experiences:
>Are there blind frontend engineers?
I don't think so. It's not that you can't do frontend at all, just that you can't do it completely. Something like copying the layout from a visual mockup doesn't really work unless someone describes the mockup to you, and even then it might not be 100 % correct, though i'd say your experience as a sighted frontend developer would definitely help there. Thankfully (in this case anyway) SPA's tend to be so complex these days that there is plenty of work to do without touching the actual layout. My frontend work has consisted mostly of refactoring and writing various integrations. Occasionally I've written some complete features where I've laid out a rough version of the UI and someone sighted in the team has finished it off for me. This strategy has worked out relatively well for me in the past. However I'd say doing solo frontend work is sadly a no-go.
> What kinds of software engineering lend themselves to someone with limited vision? Backend only?
Basically anything non-visual works out. Backend, yes, but also the business logic of SPA apps as well as devops work.
> Besides a screen reader, what are some of the best tools for building software with limited vision?
- A good editor which is accessible and has an extensive set of keyboard shortcuts. Visual Studio Code and Eclipse are the two editors that I use in my day to day work.
- Terminal. It's often much quicker to do things like text manipulation, version control and devops administration there, since you don't have to waste so much time going through information that you don't need. I've found git gui's to be particularly useless. Web browsers and editors/ide's are basically the only gui tools that I use.
Two points, neither of which is a disagreement to the OP's comments:
1. Listening to speech at 450 WPM is a totally attainable skill for the sighted. It is not some kind of magical superpower that only the blind are blessed with. It's learnt by gradually increasing the speech rate and stopping just before the speech gets incomprehensible. For the record, I can't listen to text at 450 WPM and fully concentrate for long periods of time. Novels and other long pieces of writing I read at a much slower rate.
2. Processing visual information does take processing power. However, so does inventing and using coping mechanisms in a world that has been mostly made by and for the sighted. In most cases I rarely get any advantage of being blind. I just think of new approaches of performing as equally to the others as I possibly can.
It does, yes, but with Braille I suppose the effect could become similar eventually. Actually, I find myself ignoring certain speech patterns in a similar way. For example the word "blank" which is what my screen reader says whenever encountering a blank line. I have long since stopped thinking of the word blank in those situations. It's just a sound that means that there is an empty line. I guess I would eventually stop thinking of brackets as brackets but rather just signals for grouping certain expressions, and the scope and context of those expressions would sort of come automatically much like blocks in other programming languages.
Which language is "nicest" probably comes down to experience and personal preference. For me Lisp's feel a little dense, and I find that I have to concentrate more than usual when working with e.g. Clojure. But this may not have anything to do with blindness in particular; I grew up with Python and various C-style languages and those feel the most comfortable to me. I know some very capable blind Lisp developers and their experience is probably opposite to mine.
No, I haven't really tried it. I know that it exists and that there are people who like it, but making everything work under Windows is a hassle I haven't bothered going through. (Basically I would have to write an Emacspeak-compatible speech server that would use Windows's TTS for speaking.) It could also be that Emacs and braille wouldn't work very well together in Windows, but this is also something I haven't really explored.
I am the author of "Software development 450 words per minute". As it's been 2 and a half years since I wrote this post, I thought I'd give a little update as to the tools I use since my preferences have changed slightly. (I know this comment would be more useful as an addendum to the original post, but since I'm currently on holiday it's just quicker to type everything out here for now.)
I switched to using Eclipse as my Java IDE about a year ago. The reason for this is that Eclipse is much nicer to use with a keyboard and a screen reader. The state of Java GUI accessibility is a little convoluted and I won't go into that here (look up Java Access Bridge if you're interested), but basically Eclipse works better and faster because its UI toolkit uses the platform's native accessibility API's directly. I guess the reason why I picked up IntelliJ in the first place was that literally every Java developer I knew at the time was using it, so naturally I thought it couldn't be a bad choice. Also, I had used Eclipse briefly in 2013, and let's just say it was nowhere as nice as it is today.
I have also ditched Notepad++ for daily development work. I do use it for notetaking and other similar things, but for non-Java based coding Visual Studio Code is all I use these days. I had experimented with VS Code when I wrote this post, but back then it still had some accessibility-related bugs that had to be ironed out. However, they were fixed a long time ago and I've been very happy with my experience so far. VS Code's team has been incredibly committed to ensuring their work is accessible, and these days I just expect things to work right out of the box. And this is something I usually never, ever do.
Other than that things have stayed pretty much the same. I'm still on Windows 10 and am using NVDA as my screen reader, neither of which is likely to change anytime soon. I've been slowly migrating to WSL from Git Bash but it hasn't really been a priority; for now I'm using both side by side.