Ask HN: How should a programming language accommodate disabled programmers?

I work on programming languages (as a career & hobby) and I’d like to make sure that my main language project is designed with accessibility in mind. I need some guidance & opinions from people with disabilities (e.g., blind or visually impaired people, or people with mobility issues) about your pain points with existing tools.

This doesn’t need to be just about the language itself, but the whole experience of developing with it, e.g., tooling, error messages, documentation, editor integration, &c.; as simple as “Avoid making me press Shift” or as involved as specific problems with existing tools and what you wish they did better. I’d also welcome examples of tools that do things particularly well!

So far I’ve had/implemented a few general ideas:

1. Making whitespace-sensitive syntax, like in Python & Haskell, optional syntactic sugar for explicit brackets & separators. It can also be turned off entirely, if e.g. you work with a screenreader and prefer it not need to speak all the indentation.

2. Striking a balance between concision and avoiding excessive punctuation-based syntax. I’ve also tried to make sure that visually similar characters have clearly distinct functions, so it’s less likely to mix them up—or if they are typo’d, at least the compiler should reliably detect this and produce a useful diagnostic.

3. Working on integration with existing editors (through the Language Server Protocol, an Emacs mode, &c.), so ideally you can continue to use the editor you’re comfortable with that supports your setup.

4. Allowing the interactive mode (sort of a souped-up REPL) to be customised to support screenreaders, colour settings for colourblind people, adapting gracefully to large fonts, and so on.

I’m certain there are plenty of things I’m still missing, though! So I’d really appreciate any help, personal stories, or links to the work of similar initiatives (like Accessible Scala) that you can offer. Thank you!

I wonder if it would be helpful to describe the indentation level you are on:

e.g:

  def method_here(value): # Indentation level 0
    x = 10 # Level 1
    y = 5  # Level 1
    if x == value # Level 1
      print 'x!' # Level 2
    elif y == value # Level 1
      print 'y!' # Level 2

You could maybe even throw in a block number so it's clearer.

Not knowledgable about screen readers, but maybe having the increase in indentation result in an increase in pitch of the screen reader voice could be an interesting approach for this.

You beat me to this idea by five minutes!

Another bonus to this approach is that it enforces a style guide. Overly complicated and nested programs become more difficult to understand, and excessive nesting becomes literally incomprehensible as it spirals out of the human hearing range.

I wonder if you could also use different voices for different things. Code could be read in a masculine tone, code blocks in a feminine tone, inline strings with an Australian accent.

I do rough accessibility testing with JAWS on my company website, before we get people in to give it a thorough going over.

I would suggest you try it yourself, and download JAWS and write out some simple Hello World and figure out the challenges you face and then get in touch with disabled programmers and advocates.