[zersiax]

Technically I can already sort of do that in any language. Do keep in mind that all I need to interact with a computer is a keyboard and some way to hear audio ...so I can in fact lay back on the couch with a keyboard on my lap and code away. In fact ... I do that all the time ;) I can't check my work using braille that way though, which is kind of essential with very complex code

[yaddayadda]

@zersiax

- Thank you so much for sharing!

- You mention,

>Premier tools that coders use every day, like the IntelliJ editor, as well as all its offshoots (PHPStorm, WebStorm, PyCharm), are completely inaccessible, due simply to the fact that the developers of these programs have not adhered to the accessibility guidelines. They've failed to give screen readers textual labels or accessibility descriptions to work with. The same goes for applications like SourceTree, which is slowly getting better, but is still a pain to use.

Have you tried VIM, eMacs, Sublime or Brackets; if so, how would you rate them?

What is your experience with HN's interface? I know I frequently wish there were more visual indicators of new/unread responses, but I can at least scan the beginning of messages and skip ones that I've previously read; do you have a corresponding way to skip responses?

[zersiax]

No, I have to read through all the comments over and over and quickly arrow along when I notice its a comment I've already seen. As for your editor questions: Brackets is sort of usable, but too much of a pain to actually be useful. Vim ...I really have no idea how to use it, and I think thats not a 'being blind' thing :P I should look into it more Sublime is, like the IntelliJ, completely inaccessible Emacs works well regarding you can get your braille display hooked up to Linux, which is a little tricky for me in my current configuration. Also, there's Emacspeak which I am having a hard time getting to run because I don't speak Lisp :)

[jcr]

Do you have trouble with voting up either comments or stories on HN?

If you check out the HN page source you'll notice the HTML anchors for voting are essentially empty save for an empty HTML DIV element with it's background image set to the arrow icon. Needless to say, the way it's designed is dead wrong and highly problematic for systems like terminal text browsers.

[zersiax]

Oddly enough no, I can read the vote up buttons just fine and should in fact use them more :) maybe some JS behind the scenes that is taking care of it

[tyrylu]

I'm not the original author, but a blind coder nonetheless, so i think it's worth responding anyway. Sublime is an accessibility disaster, unfortunately, Emacs can be used, but it's much more productive with EmacsSpeak or Speechd-el. Vim would likely need something similar, because the advanced cursor movement commands have no screen reader feedback by default. The HN ui is quite okay, but some semantic comment nesting (like disqus comments, perhaps?) would help. Might be some filtering for new comments since last visit.

[murbard2]

Thanks for writing this article. I've often wondered if I could still program if I lost my eyesight; this is reassuring.

When I consider at expressions with infix notations, I visually scan then from left to right and right to left. Visually matching parenthesis is also important.

I get the impression that if one were to listen to an expression in one pass, reverse polish notation would be the most intelligible. What's your experience like here? Does it make a difference?

[zersiax]

I am afraid I didn't understand most of the sentence. I am not familiar with the notation you are referring to, not the type of expression you mean :(

[murbard2]

Infix notation is when the operators goes in the middle. For instance, the expression: x * (y-z) uses infix notation. When I look at it, I can see at a glance that x is multiplied by the difference between y and z. However, were I to listen to it, I wouldn't know when to expect the parenthesis to close. I would have to remember that I am within a parenthesis.

Postfix notation, or reverse polish notation places operators after the operands. So that same expression would read " x y z - * ". The idea is that you push x on a stack, then y, then z. Then comes the minus sign, you pop the top two elements, y and z, and push their difference on the stack. Finally you pop the two elements, x and y-z, and replace them with their product.

In reverse polish notation, you still need to remember something, the state of the stack, but there are no parenthesis. I get the impression it would easier to parse if listening to the expression, but I may be wrong.

So which parses most easily for you? x * (y-z), or x y z - * ?

[am391]

Thanks for writing this post. I'm visually impaired (but not blind) and can get by making minor adjustments to my work environment (font size, contrast, etc), but reading this was truly inspiring. Thank you.

[grego]

Btw. what braille do you use for reading code? 8-dot us-computer braille, or something else?

(I'm the author of MBraille, now working on Vietnamese braille table for liblouis, so braille is in my mind...)

[zersiax]

I tend to use 8-dots US braille, simply because I am used to it. Working with other tables would work just as well though if that's what you are used to, there's no 7 and 8 dot features that set it apart