5 ms·
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
by sbahram 8y ago
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:
WCAG 2.1
https://www.w3.org/TR/WCAG21/ https://www.w3.org/TR/WCAG21/
orca Screenreader
https://help.gnome.org/users/orca/stable/ https://help.gnome.org/users/orca/stable/
NVDA Screenreader
https://www.nvaccess.org/about-nvda/ https://www.nvaccess.org/about-nvda/
speakup Project:
http://www.linux-speakup.org/ http://www.linux-speakup.org/
JAWS Screenreader:
https://www.freedomscientific.com/Products/Blindness/JAWS https://www.freedomscientific.com/Products/Blindness/JAWS
zoomtext Magnifier:
https://www.zoomtext.com/ https://www.zoomtext.com/
emacspeak
http://emacspeak.sourceforge.net/ http://emacspeak.sourceforge.net/
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.
- ndarilek 8y agoMan, I feel like half this post was my sysadmin playbook. I eventually got sick of explaining why it was such a pain in the ass to crack open vim and edit remote files, and why it was much easier to edit locally and scp back. I credit interactive fiction for the problem-solving skills, and gopher for the boost to memorization (gopher because if you wanted to find that primitive search engine 12 levels deep, you had to memorize lots of strings of numbers to navigate those mazes of menus. Not much different than how we use appliances these days, really, though it's hell to manage if you're stoned or not 100% on your game. :)
- sbahram 8y agoYeah, I hear you. Honestly the smart-home/IOT movement has been very beneficial, not because of the sorry excuses for automation being sold right now, but because it enforces a certain level of pre-2005-web-like openness. I knew all the file system structures and specific web paths back in the day because it was just necessary to memorize it and easy to access things if you had specifics, whereas now everything is cryptographic strings, super long addresses like IP V6 ones, and based on dynamic interactions so that deep URLs are pretty much worthless to memorize except maybe on sites like GitHub, where the pattern is reasonable. The reason for my comment on smart-home stuff bringing back some of this openness is only that at least now there's a backdoor, so to speak. When a microwave doesn't talk and also has very little tactile differentiation on the buttons, at least you can use your Google Home or Amazon Alexa to tell that thing to warm up a plate for 3 minutes. Same goes for toaster ovens, rice cookers, water boilers, Sous Vide circulators, thermostats, locks, lights, etc. Yet another of the countless examples of why having things be open and have an API makes it better for absolutely everyone, especially since it facilitates use cases not able to be foreseen at inception. And, yes I do believe all of that can be done in a secure and sensible way. No need for security to be antithetical to inclusion, which is a pretty popular misconception. Speaking of whacky stuff to do to access Linux and text editing, I remember back wen Jaws and even NVDA had far worse cursor tracking in the Windows CMD window, so you couldn't be sure that when your screen reader said it was beside a certain character, that it actually was. This is something I argue no sighted user of a computer has probably ever had to deal with, and never for a duration of years. So what I would do is I would type 'z' and then route the screenreader's secondary cursor to make sure that the 'z' I added was added where it would/should have been, if my cursor was in fact where the screen reader said. Just imagine needing to text edit where you can't even trust the position of the system caret .... fun times!