None of the answers were about the questions I had about how to program when you're blind. While the tools they use are interesting. I'm more concerned with how you would browse the code.
Say you wanted to find a method, how do you scroll in a large file to locate it? I guess deft use of find & go to definition helps out here.
How do you locate a line of code in a large function? Do you have to listen for the screen reader to read the contents of an entire screen's worth of code? Or do you rely on previous knowledge of the code and remember where it was?
How do you deal with debugging / fixing errors. I imagine the screen reader trying to parse the output of a template error being a nightmare.
This is certainly one of the harder aspects of programming blind - particularly tackling a large, unfamiliar, codebase. In the case of a new project, I build up a mental map of how the program works - and memorise the conceptual organisation. With an existing codebase go-to-definition is invaluable, and stepping through in a debugger is just as useful for a blind person as for anyone - you get to see the lines in the order of execution.
This does influence my personal coding style - I always have the entry point at the top, which makes use of meaningful named methods - so it looks like the table of contents of a book. Next come the second level methods - and so forth, until the small auxiliary methods are way at the bottom. This lets me read it top-to-bottom, like a story. Much of this is just good coding practice - but, for example, I find it really frustrating to read code where functions must be defined before they are used - this results in details first, outline last - which makes it hard to build up that mental model (remember, I'm listening to the code line by line - no spinning the mousewheel).
Finally, I'm going to use this comment to express my dislike for underlines (yes, I'm looking at you, Ruby). Every underline adds three syllables to my audio stream - whereas screen readers read cammalCaseCode as separate words.
It seems unfortunate that you can't configure screen readers to say "_" as "under" or some such thing. Also, I think it would be very useful if punctuation was pronounced in a different voice or tone.
That sounds like an issue with the screen reader, surely? CamelCase is arguably somewhat less readable for the seeing than underscore_separated_words, as the underscore can be read practically as a space. Presumably, you'd need a syllable to distinguish between CamelCased and underscore_text, but I don't see why you can't have Python or Ruby style underscores as a convention?
You would have hated some of the projects I've worked on - spaghetti code, full of variables like hold_value or temp_num and function names like doThing and doThingNow. As a fully sighted person, I mostly had no idea of the overarching organization of the problem. If I were blind and faced with the same project, I'd probably quit and take on something easier, like juggling chainsaws or trying out for major league baseball.
Search is a very fast method of navigation when your editors search doesn't suck. Watch an experienced emacs or vim user sometime. I can't say much about other systems but I did once spend a day working with only emacsspeak, the audio interface to emacs. With emacsspeak you use the normal emacs movement commands to move by char, word, sentence paragraph etc and it will read out the unit you've moved in, it kind of let's you scan through a document. Also, experienced users have the speech turned up really fast, if you google it you can probably find a recording...
I do use vim on a daily basis for all my remote editing needs. Just did not think of how useful all short-hands are for blind people. Thanks for mentioning it.
I had a TA at school who was blind and was excellent at helping CS students debug and fix their class projects. He helped me a number of times and was generally able to find bugs very quickly.
While I don't know the name of the program of he used, my vague recollection is that it read aloud the contents of whatever line he had the cursor on, a good deal faster than a human would speak it (I actually found the text to be read too quickly for me to follow by listening - I needed to read it myself).
I actually found this article about him on the Internet:
You can ask anyone who has been programming for 40 years or so this same question. Before we had visual editors [but after we stopped using punch-cards], we had line editors, which worked under fundamentally the same constraints as programming blind has: only a little bit of content at a time, streamed, selected before "display", and requiring a "replay" after any edits to see if the edits were correct. A description of a working day for a grizzled ed(1) veteran would probably have a lot in common with an optimal blind-programming experience.
I suspect coding blind with an audio interface is closer to a word-editor than a line-editor. Imagine your monitor showed only one word on it, or one punctuation mark, and you had to remember everything else!
(Edit: I see below there are Braille editors, which I imagine mirror line editors! Expensive though.)
Prices have come down considerably. $1300 or so buys a 20 cell display. Also, in many countries, they are subsidized.
And no, they do not really compare to a 20-character LCD display. Reason is that blind user have to rescan the line with their hands whenever something changes, and that takes longer than visually scanning it. Effectively, blind users only 'see' two or three characters simultaneously.
I was developing a Liferay portal for a client which needed (in my idea) complete accessibility. I used my iPad to move in the page and was a big experience, most of my initial design was not tested over visual appearance but semantic accessibility.
If you own an iOS device do activate VoiceOver and try to surf YOUR applications (and more important, your WEB applications). Even better, let someone else do it for you.
You'll discover how hard and difficult can be to READ a page not designed to be read but scanned with eyes.
Please, do it. Blind people have the same right to access your content and features.
I recognize that you're posing a (presumably rhetorical) philosophical question, but it seems worth pointing out that there are certain contexts where accessibility is a matter of law.
If your content is intended for use or distribution by a US federal agency, or was created using federal dollars or as part of a federal contract, you are responsible for ensuring that it is compliant with section 508 of the Rehabilitation Act of 1973, which specifies that your content be accessible to individuals with disabilities.
Leaving aside for a moment the larger question of whether specific blind and/or deaf individuals consider their sight/hearing status to be a disability or not, section 508 is generally interpreted to mean that your content needs to be as accessible as you can make it. That means (among other things) working to make sure that screen readers and other such software are able to make full use of your site's functionality.
In my experience, the process of getting a project compliant with section 508 is generally very valuable- it makes you think a lot about how your content is organized, and rewards use of semantic markup. It can be frustrating at times, but the end result is definitely worth it for a wide range of reasons.
Here are a couple of places to get started learning about 508 issues:
I see what you're getting at, but I think you're being a bit douchey about it.
Of course blind people do not have a "right" to access his content. Neither does anyone else. There is no law anywhere that says "X person or group has an inalienable right to view Google". That doesn't mean we shouldn't be considerate of disabilities.
ADD: He says blind people have "the same right" and not "a right", the implication here being that they have "the same right" as any sighted person.
Not a reply to azelfrath, sorry. chadmalik, if by chance you see this, your posts have been getting auto-killed since the "Why vertical farms are a crock" discussion.
For those without showdead on, here's the comment, which I thought was worth reprinting:
"I'd like to add another way of thinking of it. Several years ago I was part of a group working on a project that was composed of people from various companies. One of the attendees was blind. It became clear VERY quickly that our blind friend was light years above everyone else technically and in terms of thinking about process. He'd sit there, listen to people go back and forth on this or that issue, then come in with an incredibly intelligent and appropriate solution, time after time. He was using an audio browser to go over the project materials when we weren't working. If you don't make your services accessible to the blind, YOU might be the one missing the benefit of this type of person's input."
So, you're being sarcastic, but aside from the fact that you're scorning blind people for crying out loud, there are laws that might well apply to you.
Do you do any work building government websites or sites that serve other large public services? Do you sell services to schools or universities? Do you run a site that people might be obligated to use for some reason (i.e., website for a utility)?
Think of it like this: "I know it's kind of a shitty thing to block disabled folks from my site -- but given that I'm an X (offering X, hosting X, etc.), is it ILLEGAL for Xs to discriminate against disabled people?"
Laws are progressively covering more ground as time goes on, so while I doubt there will ever be much enforcement for teensy hobby sites (like the guy at the side of the highway selling strawberries probably won't be building any handicapped ramps), it's pretty reasonable to expect gradually more requirements from all serious sites. In the UK (for example) the Equality Act 2010 gets a bit more explicit that all sites should at least makes reasonable efforts for accessibility:
http://www.shoosmiths.co.uk/news/3441.asp
(Caveat: I'm not an accessibility legal expert by any means, but have been doing a bit of reading on the subject over the past year, as I'm developing a site we intend to be fully accessible).
Probably my use of "right" in that context could be not correct.
I think it's our duty to be as inclusive as possible when talking about the target audience of our applications/content.
Even more if you're designing an infrastructure used by someone else (or more the one) to build their communication channels.
And talking about a specific law and legal rights for accessibility, here in Italy every public/governative web-site/application MUST meet the required standards for accessibility. Less or more a triple A (and more given the additional strictness of our local law).
I was part of the team that rebuilt Narrator (the built in screen reader for Windows) for Vista. A few days after we had a minimal version running I tried to use it with Visual Studio to make a small change with the monitor turned off. For me it was next to impossible.
Don't feel too bad. I'm an experienced screen reader user, and even I find it almost impossible to do anything with narrator. Well, to be honest, I've only tried the one from XP. Hopefully the newer versions are better.
I have a coworker who is blind that gave a presentation a couple months ago about creating accessible websites. This isn't really about how to code; instead it is more about how to make websites accessible. He has a couple demos of using JAWS.
Just this morning my little brother pocked me in the eye, and my first thought was about how I wouldn't be able to program any more if he pocked it all the way out... Glad to know that there is still a way for blind people who have the passion and work ethic to continue coding
Interesting. This post has inspired me to actually improve the usability of my sites. Anyone have any good guides? Strangers for Dinner and edgeyo are pretty much text-driven, but what about CSS layout etc? Will screenreaders parse those?
For the most part, CSS is ignored by screen readers. However, it can of course make a huge difference for people who are browsing your site with screen magnification or who have color blindness.
I imagine it would be hard for a blind programmer to program using Python, Coffeescript and other language where white space plays important part. Can anyone give more insight about this?
Python is one of my favorite languages to program in, but the white space thing was an issue for a while. Fortunately, I found an editor that will work well with my screen reader and will tell me what level of indenting I'm at, so it's now just a mild annoyance. However, when browsing on the web or elsewhere outside my editor, I do find myself occasionally counting spaces if it's not obvious from the context what indentation level a particular line is at.
Can you elaborate on the tools you use? What IDE and screen reader do you use? Also, what tool do you use to type code with? Braille keyboard? I really interested to learn about what kind of setup that works best for blind developer.
What improvements can you think of for this? For example, parallel sound hints of other aspects of the context, like a note at a certain frequency to indicate indentation, or using stereo to indicate the position of a word?
As a blind developer, I don't think my opinions on what makes nice code differ wildly from my coworkers, with the exception of indenting, equal-sign alignment, and other such white space issues. Those are the sorts of things I only do because I have to. They rarely provide me any benefit.
Say you wanted to find a method, how do you scroll in a large file to locate it? I guess deft use of find & go to definition helps out here.
How do you locate a line of code in a large function? Do you have to listen for the screen reader to read the contents of an entire screen's worth of code? Or do you rely on previous knowledge of the code and remember where it was?
How do you deal with debugging / fixing errors. I imagine the screen reader trying to parse the output of a template error being a nightmare.