Things I learned by pretending to be blind for a week

No, that was just an SNL sketch: http://www.snotr.com/video/422/Eddie_Murphy_goes_undercover

Funny, but not real undercover.

There was a famous book called Black Like Me about a white guy who pretended to be black in the south in the late 50s/early 60s.

Those are simply nerves that run in the eye, everyone has them.

I'm a blind software developer who's been lurking on HN now for a couple years. Every few months an article about the blind comes across and seems to generate some discussion. I tend to stay quiet here on HN, as I generally feel I have little to contribute to the latest discussion on whether or not software is like a Japanese restaurant.

Now, a few points: First, and most importantly: your web sucks. I'm a very proficient computer user--the same gap between supertechnical and nontechnical users exists in the blind community, perhaps even magnified by other aspects such as secondary disabilities in a good chunk of the blind population. That aside, I've been doing this for around 13 years, using a variety of screen access solutions on Windows, OSX, and even the hellscape that is modern desktop Linux a11y. All of these solutions suffer from the same basic problem namely they are trying to squeeze a dynamic, multidimensional viewport into a linear text string for rapid communication. This don't work so hot, but like most things, you can adapt to it over time. So why does the web suck? First, a history lesson: Back in the halcyon days of the 1990's, when I was just getting started with this silly computer stuff, the problem that was desktop accessibility had already nearly been solved. Microsoft gave us MSAA, and several screen reader vendors implemented their own heuristics on top of it to give pretty good access to standard controls. Highlight detection worked ... reasonably-well to know when text changed on a form, screen readers would perform nasty little hacks including API hooking and other black magic to give a pretty good picture of what was going on at any one time. Then, along came the web. At first this wasn't too terrible. Several screen reader vendors made a stab at solving web accessibility, and thus the virtual buffer was born. The virtual buffer is where the story really gets interesting. You can follow along should you like -- I'm currently using the NVDA screen reader to compose this comment, and you can get it at http://nvda-project.org (for those who do, no I don't listen to that dreadful voice all day, there are alternatives.) Okay: So, you have a tree, the DOM, and you need to render it linearly, and not only that, but it needs to make some kind of sense. Enter the virtual buffer. Each screen reader gets a hold of the DOM through whatever ugly hacks, then renders your beautiful website with lovely topography into a flat, basically plaintext representation. Links get prefixed with "link", headings with "heading 3", so on and so forth. The software developers in the audience probably already see the problem coming, when I learned how this worked I was rather offended. So, for the screen reader, there are two single points of truth: the DOM, and the virtual buffer representation. As we all know, when a complex system includes information in more than one place, the two have a tendency to get out of sync. Consider what happens when you update your DOM with some javascript magic. The screen reader needs to, hopefully without making me lose my current place on the page, diff your changes against its current buffer, update its buffer, and somehow indicate to me that the content has changed, without interrupting my current task. Complex DOM manipulations aside, let's just talk about how poorly-marked-up your content is: For those of you who got NVDA, I invite you to explore around HN a little. Note the unlabeled links for voting, for instance. Is there any indication that the first edit field on a submission's page is where one enters a comment? And HN is hardly a dynamic website. How can one tell nonvisually (or visually for that matter) who replied to whom in comment threads? That's something that's puzzled me for a while, I just have to heuristically separate conversation threads.

Now, it's not all bad. Slowly, aria is being deployed to a variety of websites. Even more importantly, I've recently been looking into adding access at the UI toolkit level for some popular projects, especially Bootstrap.js (if a proficient web person would be interested in helping me with this it would be awesome, I'm primarily a desktop software guy (yes, the blind are one of the few subpopulations who haven't gone hole-hog for the web, and I'd argue a good reason for that is the web's lack of accessibility.)) Simple fixes -- adding aria-haspopup="true" to dropdown toggles, adding aria roles to various things can help, and I'm hopeful that work at the bootstrap and similar level will take the onus off of individual web developers.

I'm typically pretty difficult to offend, but I must say it's just a tad bit jarring to find the top comment thread on this submission be about how terrible it is to lose one's vision and how one should do absolutely anything to avoid it. Isn't this Hacker News? Where hackers talk about technical things? Mreh.

As for the article itself, a couple rather important things: Yes, I'm certain that it is extremely difficult to navigate the web as a newly-blinded person, and this is partially because of many of the issues that I outlined above. That said, if you people want to know how a blind person sees the web, don't ask a sighted person to wear a blindfold for a week and expect it to be at all representative of how someone who's been doing it their entire life does. Why not just ask a blind person? Just a few examples: Where as the author of the submission refers to headings as the primary navigation mechanism, modern screen reader users are quite lucky in that most screen reader developers have mapped hotkeys to nearly every type of HTML element. For instance, I hit f to navigate to the next form field on a page, shift+f to navigate to the previous. Similar keystrokes are available for all the levels of headings, for links both visited and unvisited, for landmarks, for tables, so on and so forth. The title attribute of a link is read in a few cases: 1: when the link is explicitly tabbed to, and 2: when the link does not have text. A perfect example of where the title attribute should* be used is for the HN voting links.

Anyhow, I think that's enough rambling for now. Anyone who would like to discuss this, my e-mail is in my profile.

One thing I am curious about is what screen sizes you use. As a sighted developer having as much visible at once is most productive. I use two large screens and the only reason I don't have a third is lack of desk space.

The laptop being used in one of the Youtube links on the page looks to be at least 14 inches.

Does screen size affect your productivity? Do you care about resolution? Do you get the smallest screen size phones and laptops?

This is an absolutely terrible idea that seems to refuse to die. No, it is not reasonable to put the accessible content in some sort of blind-only ghetto. Amazon do this, for instance, with a text-based version of their website. It makes it more difficult to maintain unless you've architected from the absolute beginning for it, and over time the text-based version becomes useless. Think of it from the perspective of someone adding new features to your webapp. Let's put it in HN terms -- you're building your MVP, launching in three days or something absurd... Are you really going to go build a text-based version of your website? Are you going to keep that updated? No. The only solution is to make the actual web, the one we all use, accessible. This doesn't mean changing what individual developers do so much as making sure that it's harder to be inaccessible than to be accessible with technical fixes, I.E. fixing Bootstrap so all Bootstrap sites are more accessible.