Ask HN: What are the best / most accessible languages for blind programmers?

Parham Doustdar (https://www.parhamdoustdar.com/2016/03/27/autobiography-blin...) is a blind programmer who lists his tools here (https://www.parhamdoustdar.com/2016/04/03/tools-of-blind-pro...). He mentions languages, and lists PHP, Go, Elixir, and Scala.

Great link! I don't think I would count Scala as he says, "Scala (I’ve always wanted to play around with this one too, but the sheer number of language features is scary and I always put it aside)"

PHP and Go are the ones he uses for work, Elixir is the one he uses at home.

I realize the rust evangelism strike force is a thing, but I can't help but think

    5 |     let scores = inputs().iter().map(|(a, b)| {
      |                  ^^^^^^^^ creates a temporary which is freed while still in use

is easier to make accessibility tools for than

    In file included from /usr/include/c++/4.6/algorithm:63:0,
                     from error_code.cpp:2:
    /usr/include/c++/4.6/bits/stl_algo.h: In function ‘_RandomAccessIterator std::__find(_RandomAccessIterator, _RandomAccessIterator, const _Tp&,...

True. A focus on accessibility typically has positive benefits for far more people than are being specifically targeted with the changes.

You may be cherry-picking pieces from your compiler output, but all up I think you’re probably choosing the wrong parts, and even caring about the wrong thing.

rustc’s (default) “human” error format is going to be very messy for screen readers to follow, because it has a lot of visual alignment and decoration. You’re going to have to leap through hoops to make it decent for accessibility tools, whereas that C++ compiler’s output might not be quite so bad in some ways. (To clarify: I expect that both tools/formats are bad for blind users, in different ways. For sighted users, I don’t think there’s much of a contest—but the distinction is in the diagnoses more than their presentation, so this difference is about everyone, not blind people.)

But I think blind people probably genuinely shouldn’t be caring much about the error messages as they appear in a terminal these days, because this span formatting is always going to be lousy without very fancy tooling to sanely contextualise it, and guess what? There kinda is such tooling already: IDEs (and with the advent of LSP, it’s even broadly cross-language). Use something like rust-analyzer with your Vim + coc.nvim (what I use) or VS Code (the most popular choice) or whatever, and you can jump between error locations easily and have it all presented with your code, rather than separately. That way, the only accessibility support required is in the IDE, and that you have a language server (which people will want anyway ’cos they’re handy).

(Since I mentioned Rust’s error formats, relevant reading: `rustc --error-format=…` <https://doc.rust-lang.org/rustc/command-line-arguments.html#...>, and `cargo build --message-format=…` <https://doc.rust-lang.org/cargo/commands/cargo-build.html#op...>. My guess is that blind people would probably be better served by the “short” error format, or by tooling that consumes the “json” error format… like rust-analyzer.)

My guess is that the rust human error format is derived from some raw format that could easily be propagated to any other UX/UI and right now we are only familiar with the CLI format. I doubt they are keeping the state with a string of "^^^^" rather than just some 'error_starts_at_char: 8' and then some pretty print function prints the ^.

With --error-format=json you can get both the underlying encoded tree as well as the cli output within a field. The later is useful for tools that don't want to do anything special beyond presenting the output inline. All the pieces are there, there just hasn't been anyone with all of interest, expertise and time to work on it.

For a while now I've been meaning to do something about this. Users of TTS interfaces and braille displays can currently rely on whatever LSP compatible IDE they might use, but I would like to provide cli output that is suitable for them either out of the box or as a wrapper leveraging the JSON output. The one today isn't fit for purpose due to the heavy reliance on ASCII art.

The big problem I see is that the ASCII art output relies heavily on contextual cues, pointing into user code that might be too long and with messages that easily go beyond the capabilities of a Braille display. There are mock ups I've done, removing and rearranging things to build output that works as if someone was talking to you, but don't have the expertise to say that it works for the target audience.

If there are people with relevant expertise reading this, I would love to pick your brain. There are simple questions like "is it useful to truncate paths to be just the file name and let users rely on their tools fuzzy search to find them?" or "is it better to just mention the place in the file we are talking about and not display a snippet? Same for suggestions?"

>I realize the rust evangelism strike force is a thing

With rust there's no buffer overflows, how will folks buy supercars to crash in the desert after escaping "flyover country"

(In all seriousness, people were obsessed with it at Mozilla but also just kept hazing me I was "just" a UX researcher -- do you know of a good primer who knows the basics of languages like Python, bash, and QBASIC but struggles with compiled languages like C/C++?)

Appreciate the vote of confidence, but I fear the default output isn't great for this usecase. In that example, you're cutting out the main message, file position and any message that comes after. It is also a single span in the main message, which is not uncommon but also not a given.

Ideally we'd provide a more narrative output with something like "file.rs, line 5, column 17, fn call to inputs creates a temporary which is freed while still in use". This would simultaneously be better for blind users, and give the people clamouring for more compact output an alternative.

In the 1980s I had a girlfriend whose father was completely blind and he was a programmer. I don’t know what language(s) he worked in (what was available in the 1980s? C, Fortran, Pascal, COBOL, uh…) and it didn’t occur to me to ask since I didn’t knowing about computers back then. I have thought many times since that it must have been harder for him with the technology restrictions of the 1980s versus today. Just documentation would be hard. No www to look things up. Even up to the early 2000s we were still using physical books for documentation. Was there any digitized documentation in the 1980s?

Or easier - I worked with a few blind people in the 1980s.

Recall that everything was a text based interface back in the day, there were no widespread GUI's and hyper graphic interactive mobile interfaces.

There were simple text to speech interfaces, not great, but they were coming along - and there were "braille boards" - that converted screen text to a strip of braille via raised pins.

Ponder that and ask yourself which age of technology was harder for blind people to navigate then Vs now.

It's easier now to build a good blind interface, but there is a vast amount of interfaces out there that are a nightmare for the unsighted with no consideration given to access.

Immediate thought: Reverse direction, and look for screen readers which have some understanding of computer language syntax. Or consider developing one yourself. Editors such as vim have been doing syntax highlighting for ~25 years now, building on that technology might be the best approach...

[Hurries into concrete bunker before the first salvo of "emacs could do..." replies arrives]

Or consider developing one yourself.

In which language? ;)

First Reaction: In the [mumble] language, which has very simple syntax, to speed up bootstrapping.

Second Reaction: The second language to support is machine-code binary - so the reader can use the voice of Bender (from Futurama) praying in binary.

[Just think logically!](https://xkcd.com/1112/)

This kinda strikes me as obviously the "right answer", in the sense that if you could have a reader traverse the code and "translate" it into English, surely you could then go the opposite router. No need for "func parentheses a comma b close parentheses"

But rather

"function definition func, two parameters, a, b"

Sorta like a prettier for blind coding

=== unicorn[0] fits in the 'easy to keep everything in memory' mental model language department without loosing expressiveness/power. language documentation page[3].

--- very high level / 6th generation level language. Makes extensive use of generators for doing goal directed programming.

=== ARC[1] terse lisp dialect by Graham & Morris

=== Cursorless is spoken editor[2]. Throat mike useful in cubical office.[3]

--- type one thing. speak another. X2 productivity.

===

[0] : http://unicon.org/ ---

[1] : https://www.owlapps.net/owlapps_apps/articles?id=188190&lang... ---

[2] : https://www.youtube.com/watch?v=NcUJnmBqHTY ---

[3] : https://kleinelectronics.com/modular-throat-microphone/?sku=... ---

[4] : https://btiffin.users.sourceforge.net/up/index.html ---

===

I'm curious to know if very terse languages like Uiua and BQN would be good for blind programmers?

I would think it eliminates a lot of overhead that is specifically designed for sighted people.

I also wonder how screen readers deal with the symbol soup.

https://www.uiua.org/ https://mlochbaum.github.io/BQN/

Forth and Lisps tend to be fairly visual syntax free as well.

I'm just speculating though, looking for someone with experience to confirm or rebuke.

Knew a person who was severely sight impaired who was fond of C.

Can't find it now; there was some online interview of them. They maintained the SlashNET custom ircd for a bit.

I worked for several years with a legally blind programmer. He got by with a level of magnification that allowed perhaps three characters on a large screen, and with a screen reader. His preferred language was FoxPro, a language I know nothing about.

Haskell seems like a candidate. It has a minimum of syntactic noise (it looks like math), and it offers the $ operator, which is great for linearizing what would otherwise be lots of nested parentheses.

It does, unfortunately, have significant whitespace. (I'd be curious to hear from a blind person whether sig whitespace is as painful to them as it sounds like it would be to me.)

Using whitespace for formatting while standard is optional, you can instead use braces. See section 2.7 of the Haskell Language Report: https://www.haskell.org/onlinereport/haskell2010/haskellch2....

This is always pointed out, and it's cool and great, but as soon as you're reading anyone else's code, you either need to read the whitespace yourself or convert to and from it. Idk, maybe that's not as bad as it sounds.

> It does, unfortunately, have significant whitespace.

Haskell is actually defined as a braces-and-semicolon langage with an off-side rule for the convenience of layout sensitive code. The transformation is simple and completely deterministic, so if delimiters and separators are preferable to a blind coder they can reasonably easily use that.

I used to help a blind guy with his Haskell on the #haskell irc channel in the 2000s. He told me he picked it because it had a very low character count. He used a screen reader so brevity was important.

Related, Ask HN: Alternatives to Scratch for a blind child? https://news.ycombinator.com/item?id=34229502

The Quorum team is actively working on an accessible block based extension of the language as well. They recently presented on it at CSAccessForAll working group my partner participates in.

I believe language does not matter. I believe the hardware that presents the text to the programmer is more important. I would think a braile terminal would work fine.

Over 30 years ago, there was a deaf/blind programmer in my group. She had no issues and was quite good. That was a COBOL shop.

COBOL! Was delighted to get to this word because I'd started wondering if verbosity mattered, and couldn't say what the value of more or less verbose would be. Any insight on that?

not really, been decades since I used COBOL

python is probably a bad choice due to the white space absolutism.

compiled languages may be not fun since you have more delays than the sighted.

what did old school phreaks use when learning to program? (i was late the the game in the late 90s, and people always assumed i was older except when it was a context they'd pay me fairly for my intellect -- then it's nothing but precarious, low paying nonprofits or piecemeal consulting designed to keep me in their orbit)

there is a library for the blind in 412, but they also block tor so i have to hope what pops up in duckduckgo is accurate:

https://duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswz...

>Library for the Blind and Physically Handicapped >412-687-2440 >Toll Free Phone Number: 1-800-242-0586

if they give you shit say that it's greg and you're using your one phone call, they'll help you if you don't start asking a bunch of kinsey crap, if they don't suffer a narcicistic meltdown from having to do more than show someone the braile forms for welfare.

(i have to be careful not to hammer resources intended for the visually handicapped when using tor -- my no javascript lifestyle means i often seek out things designed for a screen reader, and i've seen them get overwhelmed in ways i haven't seen since the 2000s)

in general, interpreted languages are easier to keep a mental model of, because they have been iterated on to the point you can write out code that looks like psudocode, it's why i like python

the hackers who trained me were big into perl, which has a lot of issues but the whole there's over 9000 ways to do things -- there's a big library of existing perl code, and since there's more than one way to do things and those people fucking love one liners you'll spend less time dealing with "whitespace" which, as a blind person, i'm gonna guess is a very hard thing to grok, harder than public key encryption, recursion, or the idea that we don't need john taylor gatto to tell us what hellen keller got up to.

Maybe you can find some ideas here: https://news.ycombinator.com/item?id=22918980

There is never a "the best" in anything. It all depends on the context. Since you provide very little to no context, my answer is; "all of them".

I managed a blind engineer for a while. My main takeaway was: avoid whitespace-delimited languages (e.g. python). Go seemed to work well.

I would think Python at the top of the list since it's syntax is very minimal. Just autoformat the tabbing.

I would think Python would be very problematic, actually. The end of a lexical block can only be detected by looking at the whitespace at the beginning of each line, and asking a screen reader to read whitespace seems like a nightmare. Compare something like Ruby, where (while not great for other reasons) a screen reader would literally say the word "end" at the end of the block without any additional setup.

edit: Of course, a decent screen reader could probably be programmed to do something reasonable here -- e.g. even saying "end" at the end of an indented block, though there are lots of options. This would need to be set up, but that might be the way -- you'll probably encounter Python at some point whether you like it or not.

I've heard good things about Braille-lang.

Python?

How would somebody blind perceive indentation in Python?

I'm not blind, but I would say that in any case you need your screen reader the ability to tell you

"the current line is inside that if , which is inside that function" when you hit a "give me the context" ? regardless of the indentation system of said language

The screen readers can say the number of indentation.

I really hope they used tabs instead of spaces .... space space space space space if ah equals equals bee ... space space space space space space space space space ...

I'm going insane just thinking about counting spaces.

Or instead of "space space space space space space space space" they could just say "eight spaces".

You are really hoping a computer will be smart, huh?

https://www.youtube.com/watch?v=94swlF55tVc

Pipe/redirect through sed to change start of line spaces to string format of #8 #; followed by rest of line.

Without semicolin after final # comments whole line.

I remember reading somewhere in a different HN thread that some tools use pitch to represent indentation depth. There are all sorts of audio cues that can be used to represent syntactic information about code.

That's really interesting. I wonder what other audio cues can be used other than the simple content of the words.

Voice, maybe? Humans are great at distinguishing lots of different voices. Are there any screen reader tools that use a mixture of different people's voices to add additional fidelity to the information?

Yes, some screen readers such as JAWS can be configured to use a different voice to represent bold text, for example. They can also use non-speech sounds to represent things such as HTML elements.

One of the things that really blew my mind is just how fast a proficient screen reader user can crank up the speed, e.g. https://soundcloud.com/freecodecamp/zersiaxs-screen-reader. It's totally unintelligible to me, and doesn't even sound much like human speech.

If you're no longer constrained by the speed and sound of normal speech all kinds of other interesting audio representations become possible.

My understanding is that most people perceive relative pitch in music (is this note higher or lower than the other notes around it) but not absolute pitch. I'd expect people to have to no trouble teasing out the indentation of a stretch of code, but if you hear just a few words out of context (which you do a lot with a screen reader... I'm not blind but I've been tasked with making sites accessible and spent a lot of time w/ NVDA) you will probably lose the thread.

It would be pretty trivial to write an AST visitor that would treat each new indentation level as an “inside [function|while|if|etc]” … that’s going to handle your already syntactically correct code. Bit harder to deal with syntax errors and mixed indentation, but if there’s a way to tell a sighted user about it there’s a way to tell a not-sighted one.

Assuming you care enough about humans to do so, mind.

I worked with a proficient blind python programmer. It didn't seem to bother him in the slightest.

Surprised the best answer is not mentioned yet: English! English is the best programming language to program people and (soon) computers.

sort of like giving a programmer an assembly dump of printf(" \n")

apl or unicorn/icon better choice.