Just learned about GridReader, a free tool for Blind programmers that might make it easier to explore complex nested code. My #Python experience is limited to experimenting with the BBC Microbit, and so far i've just set my screen reader to report indentation level. #Blind coders: how do you handle indentation and navigating complex code bases? Does GridReader seem useful? psu.edu/news/information-scien…
Michael Connor Buchan reshared this.
Quin
in reply to ChanceyFleet • • •Honestly no, from reading the article. I know blind programmers that can fly when compared to sighted programmers, so saying that we often fall behind simply is not true. In fact, this is exactly why a lot of programmers (me included) have our speech rate up well past 800 words a minute (so we don't fall behind).
I've familiarized myself with loads of codebases over the years, and I think present tooling is plenty sufficient. VSCode is now fully accessible, meaning blind people now have access to a mainstream IDE. We also have tools for our screen readers to help us code better. As you mentioned, indentation with tones, and a handy little add-on called Indent Nav, that lets you treat indented code like a tree view.
This feels like another case of the Quorum programming language (obviously being a tool instead of a language), but same concept. A bunch of researchers that did some searching into how blind people code, and decided to make a hole new tool, without checking if alternatives are accessible/already exist. I appreciate the intent, but this is a really long winded way of saying no, I don't think its that useful.
ChanceyFleet
in reply to Quin • • •Quin
in reply to ChanceyFleet • • •eet@mas.to Yep, indent-nav is an NVDA add-on. Basically the way it works is this: if I'm in a text field, on a function, called do_work, and there's a function right below it, called work_harder, I can press alt+NVDA+down arrow to jump down to that function, and alt+NVDA+up arrow to jump back to where I was previously. It skips all the indentation between, and gives me audible feedback to indicate this. It also changes how long this sequence of sounds goes on for to reflect how much code I've skipped over, and how indented it is. Perhaps an audio demonstration would allow me to explain the feedback a bit better.
Now, lets say I want to go into the do_work function, but just see what's on the first indentation level. So, I press alt+NVDA+right arrow, and I'm put inside it (moved to the next block with more indentation than my current line). I can then use the aforementioned commands of NVDA+Alt+up/down to navigate statements, and I can keep doing this to find what I want really quickly. Its remarkably similar to a tree view.
Also, because we now have access to VSCode, a mainstream IDE, we get so many more tools. Want to know what a function expects? Control+shift+space, and its spoken. Want to see a definition? F12, boom. Etc.
Talon
in reply to Quin • • •Other IDE's like Jetbrains stuff and Visual Studio are also accessible, as well as XCode, but so far, none of them beat VS Code. Especially with features like outline explorer, which I end up using much more than I expected, the sounds for errors on a line and folded code and so on that just come with VS Code out of the box and automatically get enabled if you're using a screen reader, the fact that hints like parameter hints, auto completion, the actual errors, etc. all get read, it's great. I would never want to miss it.
I see some really cool new ideas happening with code editing nowadays, but sadly, none of them seem to take accessibility as seriously as VS Code.
Sorry if I didn't add too much to the thread. I just wanted to rave about how awesome I think VS Code is.
As for languages, most of them are quite workable. I personally get lost in symbol noise, so I like a little bit of explicitness, but I know people who're the exact opposite of me, so I believe we have opinions that are based on quite similar things as sighted programmers. I don't think blindness has ever prevented me from using and enjoying a language. And if everything else fails, screen readers usually have quite capable speech altering support through the use of word or phrase dictionaries, symbol processing, etc. So you can customize it how you'd like. Things like turning "semicolon" into "semi", "left/right brace" into lace or race, () into NoParams instead of (left parenthesis right parenthesis", "exclamation mark" into "bang", etc etc.
Toni Barth
in reply to Talon • • •Talon
in reply to Toni Barth • • •Toni Barth
in reply to Talon • • •Talon
in reply to Toni Barth • • •André Polykanine
in reply to Talon • • •Quin
Unknown parent • • •@fireborn Probably not that hard, actually. AXTextField and AXTextArea totally expose the content of each line. You can use simple string manipulation to determine the indentation. Indent-beeper did it, actually. Not sure on the license of that code, but you could at least look at it for a general idea. I'm not sure, however, if you get all the lines as an iterator/table, so you can loop over them. Sounds like a good use for Obj-Info :).
That said, I don't really need it on the Mac. In TextMate, the symbols mode on the Rotor lets me fly between functions, and that's typically all I need to do. For those times when I need to do more, though, a Hammerspoon version would be extremely useful
Quin
Unknown parent • • •Apple Developer Documentation
developer.apple.com