Hacker News new | ask | show | jobs
by ctoth 4915 days ago
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.

1 comments

Just a quick note to say that I did not mean to encourage replies to this comment by e-mail instead of using the comment system -- It's plenty useable enough for me to engage, and it's not until I reread my comment after the edit window had closed that I realized I gave that impression.
I find your long comment somewhat hard to read because there are so few breaks, especially in the second block.

(It's probably because the layout is not optimized for very long texts; it's hard to find the beginning of the next line when there are so many of them and the distance between them is small like this.)