1. 程式人生 > >Ask HN: Resources for blind developers and sysadmins?

Ask HN: Resources for blind developers and sysadmins?

This is a pretty broad topic, and many people have spent their lives working in the digital inclusion and accessibility space, so I don't mean for this to even remotely be exhaustive, but at a high-level, I can offer some thoughts that may be of help.

Let's consider two groups for now, though there are many others. Folks who are blind or have pretty impaired vision and then those who have some usable vision. For those of us who are blind or mostly blind, we use speech and Braille to interact with technology instead of a visual user interface (UI). The program that translates the UI into speech/braille is typically a screenreader. On Windows, the two popular screenreaders are Jaws and NVDA. Jaws is proprietary, costing upwards of $1K to $1.5K depending on add-ons, etc., and was widely considered the best game in town for the longest time. around 11 years ago, two blind guys out of Australia, Mik and Jamie (Jamie now works for Mozilla), rightfully thought it was ridiculous that an already disadvantaged audience should have to pay more than what most folks pay for their computers to access them, and so they worked on the free and open source NVDA screenreader , which stands for non-visual desktop access. Anyways, on Mac, there's the built-In VoiceOver screenreader from Apple, though the mobile instantiation of this screenreader, the one that is built into every single IOS, WatchOs, and TVOS device tends to be superior to its desktop counterpart, which is suboptimal wen it comes to surfing the web, interacting with programs, etc. in my and others' opinion.

For our second group, there's screen enlargement. Hell, back in the DOS days, I would have my nose on the glass of the CRT monitor to read the text, which I enlarged a bit because my brother showed me the 'mode 40' command which did 40 lines per screen instead of 80, thereby doubling the height of characters and at that time, making them readable to me. Now, I rely purely on screenreading-based approaches. Programs like the magnifier built into Windows and Mac, ZoomText, and others exist to enlarge the contents of the display, change foreground and background colors far past OS capabilities, offer auto-panning and focus-tracking, and generally act as you would expect a smart magnifying glass to behave. Again, shout out to Apple here: all of their devices have this feature built-in.

So, in Linux land, we've got the Orca screenreader. Joanie has done a truly incredible job managing that project and the volunteer community is awesome, but it's not anywhere near as resourced as NVDA, for example. Therefore, I consider Orca a labor of love and the best tool around for accessing the Gnome desktop, but it's not as fully-featured as NVDA, Jaws, etc. again IMHO. On Linux natively, there is also the SpeakUp screen reader, which patches directly into the kernel and intercepts input/output buffers. SpeakUp has the advantage of getting you speech earlier to boot-time, and it supported/supports a myriad of hardware synthesizers, which is still a big deal for a subset of screenreading users. It does not work in GUI environments though. I'd be remiss if I did not point out Emacspeak, though it is a self-voicing Emacs environment with all the advantages and disadvantages therein. Gnome, and maybe KDE?, also has magnification, but it's been a little while since I've played with this, so not sure if it's just using magnification primitives of basic video card driver stuff, actually manipulating underlying windowing primitives, etc.

So, I know that's a ton of background/lead-in, and I apologize, but I just wanted to contextualize some of these answers. Also, note that I'm leaving out a solid 90% of things.

For sys-admin stuff, back when I did a lot more of it, I would use my windows laptop and then ssh to access an army of machines running various operating systems, mostly Linux. I would write scripts in Perl, later Python, to automate things for me, as most sysadmins do. I would usually find a way to edit on my Windows PC, and then transfer the files to the right place. Over the years, this has seen me explore everything from samba shares, SFTP-mapped drives, two terminals open with an up-arrow of an scp command prepped to go, shared drives with multiple OS environments accessing it like in the case of VMWare mirroring out a disk, etc. etc. The reason for this is that editing on Windows tends to be far more accessible than relying on the interplay of nano or vi within an ssh window. Don't get me wrong, if I need to dip in an change a hosts file, quickly edit an nginx config, go modify a crontab entry, whatever ... those are doable with a nano or vi invocation in my ssh window, but for more complex editing (think back to going through all the lines of php.ini or making sure fstab is all good, etc.) then I would bring the file to windows, edit and send back. Yes, this is as annoying as it sounds, and I used to be a wizard at fromdos and the tofrodos tools, etc.

Anything web-based is of course froth with whether or not its accessible. Hell, HN isn't exactly great in this space, having some truly avoidable and bad web accessibility (just saying ... would take less than a day to make this website so much easier to use with a screen reader). For what I mean by web accessibility, take a look at the WCAG 2.1 by the W3C. I'll put links at the bottom of this message for as many things as I can think of. I mention web accessibility, though, because of tools like PhpMyAdmin, SQLBuddy, the web interface on routers and switches and PDUs, etc. There again, I like Ubiquiti products for example, since I can ssh into them and go to town.

Other sysadmin tasks involve things like port scanning, network traffic capture, setting up permissions, installing applications, etc., which are all done in similar ways, but it's the "how" that's different, not the "what", if that makes sense. I use nmap just like you for port scanning, but I may do stuff like redirect the output to a file that's growing and then use notepad or wordpad to consume that file as it grows, or 'tail -f ' it with greps sprinkled into the pipe chain just to make it less noisy.

Speaking of output being noisy, conventions matter, right? So, for example, imagine parsing a web access log with speech. You can visually just gloss over the timestamp and host information to get the crux of what you want to look for, but I have to listened to most/all of that content to get to what I want. To this end, I would either specify different format strings to put important information up front on the line, but then I've got non-standard logs, or do creative things with awk/gawk/perl one-liners, etc.

I feel this has turned more into high-level thoughts and less tools, so maybe I should end with apologizing that I'm not sure I even remotely answered your question, but felt this info could add some context to the discussion. If you are looking for highly specific strategies and targeted solutions, I would be happy to speak with you one-on-one over email, voice, etc. I believe strongly in paying things forward, and there have been many folks who have helped me along the way.

Fun fact, I wrote this in Outlook's new email window, spell-checked it a bit, and then pasted it into HN's edit field. Something that may seem totally weird, but a type of computer interaction I don't even think about anymore, even though it's probably quite different than how most folks use various applications, web or otherwise. The reason for this is that the affordances of web edit fields, even when some accessibility has been taken into account, are minimal in comparison to far more accessible interactions like the new message window of Outlook.

Some links:

cheers, and I do wish you all the best with your vision. Thank you for asking this question on HN. I hope others contribute to the conversation and this gets some increased awareness.