
Ask HN: How should a programming language accommodate disabled programmers? - evincarofautumn
I work on programming languages (as a career &amp; hobby) and I’d like to make sure that my main language project is designed with accessibility in mind. I need some guidance &amp; opinions from people with disabilities (e.g., blind or visually impaired people, or people with mobility issues) about your pain points with existing tools.<p>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, &amp;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!<p>So far I’ve had&#x2F;implemented a few general ideas:<p>1. Making whitespace-sensitive syntax, like in Python &amp; Haskell, optional syntactic sugar for explicit brackets &amp; 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.<p>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.<p>3. Working on integration with existing editors (through the Language Server Protocol, an Emacs mode, &amp;c.), so ideally you can continue to use the editor you’re comfortable with that supports your setup.<p>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.<p>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!
======
informatimago
Lisp:

\- Avoids the use of gratuituous special characters: (a b c)

\- use-dashes-in-symbol-names-instead-of-underline-so-its-easier-to-type (you
can still use underlines or most any special character, but we like to keep it
simple and easy).

\- has a simple prefix syntax, that makes it easier to read and understand
complex expressions: (loop (print (read (eval))) So no risk of confusing
special characters or syntax: the meaning is clearly labelled by the first
symbol of each expression!

\- is not whitespace-sensitive, how can you see the size of whitespaces when
you're blind?

\- includes a reader and a pretty printer, so the code can be processed and
formated automatically easily for either sighted or blind programmers.

\- time-sharing was invented for the lisp REPL by the authors of lisp!

\- as a good integration with emacs, which itself has a good integration with
various tools such as screen readers, vocal commands, etc, and it's fully
customizable.

[http://cliki.net/](http://cliki.net/) [http://common-
lisp.net/](http://common-lisp.net/)
[https://en.wikipedia.org/wiki/Common_Lisp](https://en.wikipedia.org/wiki/Common_Lisp)

~~~
dan-robertson
Well it seems that OP needn’t bother as this problem is already solved. You
wrote (loop (print (eval (read)))). How does that go with a screen reader?
Like:

Bracket loop bracket print bracket eval bracket read bracket bracket bracket
bracket?

The key thing I think is balancing and shifting parens.

    
    
      (loop (print (eval)) (read))
    

Is quite hard to sound different from

    
    
      (loop (print (eval (read))))
    

And more crucially what about the difference between these two:

    
    
      (let ((x (f))) (g x) (g x))
      (let ((x (f)) (g x)) (g x))
    

(I think writing these on a single line makes them written more like they
might be spoken)

On the other hand I think being able to modify the syntax structurally is a
big advantage.

Going back to the topic of the OP I think a useful thing is putting functions
after their arguments, and optimising to have single arguments or most non-
main arguments being typically small. For example something more like

    
    
      read
      | eval
      | print
      | loop
    

And maybe some way to do arguments like

    
    
      read stdin 
      | eval some-environment 
      | print :pretty
      | loop

~~~
Someone
_”Bracket loop bracket print bracket…”_

A screen reader need not literally read what’s on screen. It typically doesn’t
with prose, where punctuation isn’t spoken, but affects timing and intonation,
and abbreviations often are expanded (iOS speaks “Dr. John St.” as “Doctor
John Street”, for example, but “St. John Dr.” as “Saint John dee-ar”.
MacinTalk used to know that ‘Dr’ means ‘Drive’)

So, it need not do that here, and could say

“call _read_ , _eval_ it, _print_ the result, and call _loop_ on _print_ ’s
output”

, using intonation or voice to indicate the difference between content read
from the screen and text describing it.

Farfetched? Maybe, but take a look at what screen readers do with html.

A screen reader that knows lisp semantics could go even further, and replace
_loop_ by _repeat forever_ or something like it.

~~~
dan-robertson
Requiring a sufficiently smart screen reader seems a bad way to go. 30 years
on from CLtL we still don’t have a sufficiently smart compiler and I would
argue that that problem is easier. One thing is that this works “better” with
one-argument functions. Consider:

    
    
      (with-open-file (*standard-output* foo)
        (print x))
      (print y)
    

Vs

    
    
      (with-open-file (*standard-output* foo)
        (print x)
        (print y))
    

How do you read the first? As “print x, now with-the-file foo-open-as-
_standard-output_ it; then print y”? Or maybe “with foo opened as standard
output, print x; now print y”?

This seems more reasonable but how do you write the second example? Like “with
foo opened as standard output, print x; also print y”?

There are reasonably large semantic differences in such cases and many
programming languages, including lisp, express them with subtle hard-to-
pronounce differences in indentation or parenthising of expressions.

------
Teknoman117
One of the software engineers where I work is completely blind. I've never had
a chance to interact with him as he's in a remote office unfortunately. He
mainly writes in Python, bash, and C.

From what I understand, every project he works on has strict formatting
requirements (can't commit until the linter passes, etc.) and his screen
reader is programming language aware.

Although, to be honest, I feel that the thing he relies on most is his rather
amazing ability to remember most of the exact contents of whatever file he's
working on.

~~~
dmos62
I would find it very interesting to read your coworker's account of what
programming is like. Or anyone's account who has to approach programming
differently compared to the average person. I'd love it if more people blogged
in general.

~~~
rane
Check this out: [https://www.vincit.fi/en/blog/software-
development-450-words...](https://www.vincit.fi/en/blog/software-
development-450-words-per-minute/)

------
bdarnell
T.V. Raman (author of Emacspeak) has said that "S-Expressions are a major win"
for visually-impaired users because they give you a good way to navigate the
code structurally ("go to beginning of expression" is more accessible than "go
up one line").

[https://tvraman.github.io/emacspeak/manual/Emacspeak-And-
Sof...](https://tvraman.github.io/emacspeak/manual/Emacspeak-And-Software-
Development.html)

------
blakewatson
My struggle is typing. I use an onscreen keyboard
([https://www.blakewatson.com/journal/writing-and-coding-
with-...](https://www.blakewatson.com/journal/writing-and-coding-with-the-
accessibility-keyboard/)), which I have heavily customized for web
development.

I would appreciate terseness. For example, I love how in JS, I can do this:

``` var cat = whichCat(); var catPosts = posts.filter(post => post.cat ===
cat); ```

Whereas in PHP, I have to do this:

``` $cat = whichCat(); $catPosts = array_filter($posts, function($post) use
($cat) { return $post->cat === $cat; }); ```

So much extra typing.

DISCLAIMER: didn’t test this code so chance of typo is 99%.

~~~
melling
Have you had any luck with programming by voice?

[https://github.com/melling/ErgonomicNotes/blob/master/progra...](https://github.com/melling/ErgonomicNotes/blob/master/programming_by_voice.org)

------
gostsamo
Another blind developer here with his two pens. I like python because it has
no braces. Sometimes the screen reader does not read them or if it does, it
takes time to process the info and you still could be confused about the level
of nesting. That's why in university I reformated all of my lisp code to
follow the indentation rules of python as it helped me keep track. Generally,
if the language has no too much strange symbols with important meaning, they
are all just text to be read. So, the language is not an issue for me, but the
tools to read/write/compile/debug. In that line of thought, if it works on the
command line, it is good. Make it readable, make it verbose and avoid fancy
syntax so that there is no ambiguity when reading.

~~~
vu47
I never thought about the concept of programming in symbols that you've never
before seen. That's rather fascinating. The human brain is incredible.

~~~
evincarofautumn
I’m not sure, but based on what statistics I can find, it seems most blind
people aren’t congenitally blind, so they probably have some familiarity with
the symbols, maybe depending on how old they were when their visual impairment
manifested. And of course you could always learn the shape of an unfamiliar
symbol by feeling a physical representation of it—like on embossed paper, or
those letter-shaped fridge magnets—but I dunno how common it is to do that.

If you don’t know the symbol at all, though, that could definitely make things
more challenging to learn, since then the notation is (even more) arbitrary. A
lot of programming languages’ symbol choices are _visually_ mnemonic: Perl has
“$” for scalars, “@” for arrays, and “%” for hashes because dollar-sign _looks
like_ S for scalar, at-sign looks like A for array, and percent-sign looks
like a pair of things (a key and a value), but there’s nothing about these
symbols semantically or in their pronunciation that suggests their Perl
meanings.

~~~
gostsamo
It is not about if I've seen the symbol or not. { for example is read as "left
brace". It takes the screen reader the time to pronounce two words with
ambiguity left. What about ${variable}? You have 3 extra symbols totaling five
words to surround a single variable. Redundant and abhorrent.

------
newen
Blind people already do programming. I know a blind guy who can code really
fast, much faster than my colleagues, no idea how though.

Shouldn't you be researching how they code now and then work from there? I
actually feel like current way of coding using text works very well for blind
people.

~~~
codechapin
I have arthritis and my hands had been affected a lot, I actually like it when
the languages are more verbose. Because I can use "Procedural memory" and can
be more automatic. My hands already know how to type those words. Symbols or
short words force me into more conscious typing and/or move my fingers in a
not familiar way.

------
projectramo
It is interesting that you're getting a lot of suggestions from people that
don't claim to have disabilities. Perhaps few of them read hacker news?

It seems that their needs would vary. One thing you could do is try to an
interface to test it yourself.

I tried to write and edit a document once using just voice commands. (Let's
say someone has carpal tunnel and needs to use voice commands). It was eye
opening. I realized how much more frustrating it is to go back and try to
delete or fix something than anything else. And if the software didn't
recognize an unusual word, it was really hard.

Dragon dictate -- the software I used -- had already learned a lot of this
over the years, and there were many commands for changing that, or deleting up
to a point. The hard part was moving the cursor to exactly one spot and then
talking in a new word.

Anyway, if you tried something like that you would learn a lot.

Imagine if you are blind folded, and have to hear the program and then have to
keep it all in memory. Well, that is a _lot_ to keep in your working memory. I
would want some kind of canonical "view" to always get to in order to find my
way around.

I am glad you are working on this.

~~~
dmos62
> I tried to write and edit a document once using just voice commands. (Let's
> say someone has carpal tunnel and needs to use voice commands). It was eye
> opening. I realized how much more frustrating it is to go back and try to
> delete or fix something than anything else. And if the software didn't
> recognize an unusual word, it was really hard.

I've tried that as well. It was very frustrating. I used the Windows speech-
to-text features.

Programming code is made to be typed and read. If you can't do either of those
reliably, you'll be simulating that you can, which sort of by definition can't
work well, because if you could simulate being able to write well, then you
wouldn't even call that a disability, you'd just be different.

What I'm getting at is that the problem is simulation. Ideally, there would be
a way to program by voice (or with a mouse, etc). Not program by typing code
with voice, but find a way to describe a program (i.e. program) via voice. A
voice-centric toolkit. I hope I'm not being too vague.

What we have now is such a typing-centric development world that we don't even
think about all the other possiblities. Isn't the modern laptop just a really
fancy version of a 100 year old typewriter?

I think Bret Victor would have a lot to say about this [0].

[0]
[http://worrydream.com/#!/TheFutureOfProgramming](http://worrydream.com/#!/TheFutureOfProgramming)

------
Sir_Cmpwn
As an aside, I've been working on accessibility on the side, as part of my
work on sway[0]. My current goal is, as a sighted person, to be able to
comfortably and productively use my computer for all of my normal tasks
without any displays plugged in.

To this end I've been making plugins for Vim and WeeChat, and a script for
sway:

[https://github.com/SirCmpwn/vimspeak](https://github.com/SirCmpwn/vimspeak)

[https://git.sr.ht/~sircmpwn/dotfiles/tree/master/.weechat/py...](https://git.sr.ht/~sircmpwn/dotfiles/tree/master/.weechat/python/talkative.py)

[https://git.sr.ht/~sircmpwn/dotfiles/tree/master/bin/swaytal...](https://git.sr.ht/~sircmpwn/dotfiles/tree/master/bin/swaytalk)

If you or someone you know would find these useful, please reach out so I can
learn more about your needs.

[0] [https://swaywm.org](https://swaywm.org)

------
DoreenMichele
I founded and co-own the google group Blind Dev Works. I have posted this Ask
to it. It has at least a couple of blind developers on it and a stated purpose
of improving programming tools for blind developers. You are welcome to join
it.

[https://groups.google.com/forum/#!forum/blind-dev-
works](https://groups.google.com/forum/#!forum/blind-dev-works)

(I am seriously visually impaired, but not blind. I know a little HTML and CSS
and I have a part-time position with the spiffy title of Webmaster, but I'm
not really a programmer.)

------
geocar
Moore indicated one of the motivating factors in choosing colour was to
accommodate his failing eyesight[1]

I have previously attempted to program blind and reported some of my
experiences[2].

[1]:
[https://en.wikipedia.org/wiki/ColorForth](https://en.wikipedia.org/wiki/ColorForth)

[2]:
[https://news.ycombinator.com/item?id=9284567](https://news.ycombinator.com/item?id=9284567)

------
hood_syntax
Just want to note that in Haskell, whitespace syntax _is_ syntactic sugar for
brackets etc. I don't recall that being the case for python. Interesting
tidbit, some of the big names in the Haskell community have very idiosyncratic
coding styles that use the bracket look.

~~~
lgas
Can you point out an example or two the bracket style that I could take a look
at? Thanks.

~~~
evincarofautumn
Simon Peyton-Jones is (was?) known for writing blocks in “aligned” instead of
“hanging” style, with separators in prefix:

    
    
        someFunction =
          do { foo
             ; mx <- bar
             ; y <- case mx of { Just x -> do { baz
                                              ; pure (quux x)
                                              }
                               ; Nothing -> do { fnord
                                               ; blurch
                                               }
                               }
             ; xyzz y
             }
    

I find it nice enough to read, particularly because it leads to rapidly
increasing indentation and consequently discourages deeply nested code, but
it’s a bit of a pain to edit & diff. I would write the above like this:

    
    
        someFunction = do
          foo
          mx <- bar
          y <- case mx of
            Just x -> do
              baz
              pure (quux x)
            Nothing -> do
              fnord
              blurch
          xyzz y
    

This prefix delimiter style is actually fairly standard in Haskell not for
“do” notation, but for records and lists, since Haskell doesn’t allow a final
trailing comma in these structures:

    
    
        list :: [Text]
        list =
          [ "this"
          , "that"
          , "the other thing"
          ]
    
        data Numbers = Numbers
          { numI :: Int
          , numF :: Double
          , numS :: Text
          }
    
        record = Numbers
          { numI = 1
          , numF = 1.0
          , numS = "one"
          }

------
TheSwordsman
At GopherCon 2018 Julia Ferraioli gave a talk titled "Writing Accessible Go".
She's challenged with some vision impairment, and shares some of her struggles
in trying to be a programmer with those challenges. Of course it's
contextually about Go, but I think what she talks about applies to current
languages and those to come in the future.

\-
[https://www.youtube.com/watch?v=cVaDY0ChvOQ](https://www.youtube.com/watch?v=cVaDY0ChvOQ)

------
AndrewSChapman
I've seen some programmers code using voice. This is really handy for people
without functiong hands or fingers. They tend to use voice recognition
software like Dragon and various plugins.

I'd say from a programming language point of view, having keywords that are
short (single word would be ideal) and phonetically distinct is really
important.

One python programmer I watched on Youtube made his own vocabulary of strange
sounds that he trained his software to recognise and translate to real
keywords.

~~~
folkrav
This might be the programmer in question. Pretty impressive.

[https://www.youtube.com/watch?v=8SkdfdXWYaI](https://www.youtube.com/watch?v=8SkdfdXWYaI)

~~~
melling
There are several other newer resources:

[https://github.com/melling/ErgonomicNotes/blob/master/progra...](https://github.com/melling/ErgonomicNotes/blob/master/programming_by_voice.org)

------
gus_massa
> _Making whitespace-sensitive syntax, like in Python & Haskell, optional
> syntactic sugar for explicit brackets & separators._

Interesting question. A few years ago, I worked with a blind mathematician. I
was an undergraduate T.A. and he was the main T.A. of the course. He used the
screen reader a lot. In particular, he has the list of exercise in LaTeX. We
read aloud the grades of the students and he wrote them in the Excel form.

I don't remember him using a programming language (excluding LaTeX). The
indentation looks like a difficult problem, even if the language has explicit
brackets. Does the screen reader say "Tab Tab print ten semicolon"? Does it
ignore the indentation? Spaces vs tabs? ...

Do you have some group of blind programmers that you can ask about their
current setup?

~~~
TheCoreh
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.

~~~
pavel_lishin
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.

------
WalterBright
Perhaps instead, adapt a screenreader that understood C syntax, and instead of
reading punctuation would read it in a higher level form, such as:

    
    
        for (int i; i < 10; ++i)
    
        "for each int i from 0 to 10"
    

instead of:

    
    
        "for left paren int i semicolon i lessthan 10 semicolon
        plusplus i right paren)"

~~~
mbo
This is what the Accessible Scala initiative did

[https://www.scala-lang.org/blog/2018/06/14/accessible-
scala....](https://www.scala-lang.org/blog/2018/06/14/accessible-scala.html)

------
traverseda
Have you looked into projectional-editing? The basic idea is that your code is
stored not as text, but as data. The data is then projected into a textual
format for editing.

That seems like the best way to support disabled programmers, as it gives them
the flexibility to make whatever syntax works for them, as long as your core
AST is simple enough.

~~~
geocar
I can attest to this: Paredit is as easy to use with eyes as it is without.

------
dranov
> I’d really appreciate [...] links to the work of similar initiatives

Take a look at Quorum, a "programming language which is designed to be
accessible to individuals with disabilities and is widely used in schools for
the blind".

[0] - [https://quorumlanguage.com/](https://quorumlanguage.com/)

[1] -
[https://www.youtube.com/watch?v=X29BuzGHlBs](https://www.youtube.com/watch?v=X29BuzGHlBs)

~~~
diverightin63
My first thought as well. It is an interesting project!

------
genemachinery
Working with handicapped programmers with vision and hand issues I feel
programming tools like Mu Pyhton and Blender were invaluable in giving the
programmmer graphical feedback. Both Mu and Blender allowed interfacing with
hardware in new ways. He is now a biomedical engineer at Medtronics designing
physics models for medical devices. He started using Maya, Blender, Logo,
Scratch, Python. He was trained at the NM Supercomputer Challenge in 3 Day
events at New Mexico Tech in Matlab, Jupyter Notebooks, R Studio, AI and
machine learning. He also build Raspberry Pi, Arduino projects after taking
algebra in 4th grade and electronics at community college in 5th grade.
Computers have allowed him to excel in almost every academic STEM area. He has
had internships in bioiformatics and medical device analytics. His
programming/electronics skills are not from the classroom but from multiple
projects he developed.

------
dan-robertson
One thing which I think might be useful for speaking code is to try to avoid
needing a mental stack or going backwards as you go through code (at least for
English speakers. Maybe other languages are different). For example consider
reading aloud:

    
    
      x = some_function(something_else(y), z)
    

You first need to keep in mind “x =”, then “some_function”, then think about
what something_else(y) means, remember about some_function, think about z,
then remember it all goes into x.

Now compare:

    
    
      something_else(y)
      -> some_function(z)
      :> x
    

Read forwards as “do something_else(y), now take it and do some_function to
it, modified as z; now put it into x.”

~~~
timdavila
Yes, for me SQL is very hard to reason about just because of the way it's
"phrased"

It's much easier for me to interpret JavaScript or PHP method chaining. I find
myself struggling when I can't use an ORM.

~~~
dan-robertson
I disagree with this. I think sql is actually mostly very good, with the
exception that maybe the FROM clause should come before the SELECT.

~~~
timdavila
It's probably just the way my brain works. After a SQL statement goes to more
than ten lines or so I have to study it very hard to understand what's going
on.

Maybe it's the way I was taught.

------
Shalomboy
Just wanted to chime in to say thank you for your consideration of visually-
impaired programmers with suggestion 1.

------
spmealin
Blind programmer checking-in, here are a few thoughts sparked by the comments
that I’ve read…

Disclaimer: these are my thoughts, and should not be generalized to all blind
programmers.

First, let’s start with the supporting technologies, mainly screen readers.
The most popular screen reader is Jaws for Windows (expensive product),
followed by Non Visual Desktop Access (opensource product), distantly followed
by VoiceOver (your only choice for Apple products). My main day-to-day driver
is NVDA, but I also use Jaws for my job. I do not use a braille display. The
IDEs that I use are Visual Studio (C# development) and Visual Studio Code
(Python and Javascript development).

Indentation-sensitive languages such as Python really aren’t that difficult to
use, once you figure out how to get your screen reader to announce indentation
levels. Typically, the screen reader only announces indentation changes when
there is a difference from the line that you are coming from. A sample Python
function would read as follows as I press the down-arrow to read line-by-line
(note that I’m purposely not putting in line breaks, since an audio-based
screen reader is inherently serial):

“def foo left paren right paren colon, four spaces number say hello world,
print left paren quote hello world quote right paren, zero spaces blank”

Interestingly, I find lisp one of the most difficult languages, since there
are so many parentheses, and it’s difficult to keep track of what nesting you
are in.

Screen readers are not programming language aware. It’s all text to them.

Using pitch to communicate information is more distracting than anything.
Imagine that you were having a conversation with someone, and every few words,
their voice completely changed. It makes understanding the meaning of what
they are saying more difficult, since your brain is too busy going “hey,
something changed!”

Some additional reading that I recommend is “An Exploratory Study of Blind
Software Developers”, which can be found at
[https://ciigar.csc.ncsu.edu/files/bib//Mealin2012-BlindDevel...](https://ciigar.csc.ncsu.edu/files/bib//Mealin2012-BlindDevelopers.pdf).
That identifies some programming challenges that participants face, as well as
some of the areas that blind programmers self-report as excelling in. Full
disclosure, I was the primary researcher on that study.

Finally, a mini soapbox rant: something that I see quite often is people doing
blindness “simulations” for a short period of time. They then write up their
experience, which isn’t a bad thing, but then present their work as “I found
this hard, so all blind people must find this hard.” Identifying when a task
has a large learning curve is important, but also do keep in mind that people
who are blind have significant experience in identifying ways to overcome
potential accessibility problems.

------
Nomentatus
This has already been alluded to, but please let me do everything I can via
the mouse, especially when reviewing and reading code. I'm flat on my back
with the monitor above me, it's infuriating to grab the keyboard for a single
character of input, unnecessarily, then go back to the mouse. I might also
mention that those with sensory processing disorder (such as those on the
Autism Spectrum) will want to change the background color. (word)

------
GuB-42
Just a random thought. Is there a programming language for dyslexics?

Considering that dyslexia is a reading disorder, I suppose that the
programming language can be really important.

~~~
Someone
Some languages help with misspellings by not just saying _“‘foobra’ is not a
function”_ , but also _“but ‘foobar’ is. Did you mean to write that?”_.

I guess you could also require the edit distance between identifiers to be at
least X, but I expect that to be wildly impopular, if only because its effect
on identifiers in libraries.

------
AdmiralAsshat
Slightly off-topic: how do blind programmers read code? Does the screen reader
recite it aloud and just say "int main left-paren void right-paren open-brace
int i equals zero...", or does it use some other kind of auditory vocabulary
to make it more meaningful to the listener?

I've been thinking about this alot lately because I've been wondering how I
could get better at programming while driving on my daily commute.

~~~
cortesoft
The blind people I have known use a Braille display to work with a computer

[https://en.wikipedia.org/wiki/Refreshable_braille_display](https://en.wikipedia.org/wiki/Refreshable_braille_display)

~~~
robin_reala
Braille’s somewhat dying off as screenreaders become more integrated into
computer systems - a system reading to you (usually at 3x speed as well) has
massively more information density than a Braille display, to the point that
it’s becoming less usual to learn Braille in the first place.

~~~
evincarofautumn
Last I knew, Braille displays are also pretty expensive, slow, and prone to
breakage. Cool idea, but doesn’t work as well as a screenreader in practice
for most people.

------
mygo
Sure this problem can be addressed at the language layer, but as you've
alluded to, I think it would be more applicable to address this issue at the
text-editor / IDE layer or even the build tools.

There's tons of IDEs that make developers better at coding, with things like
automatic syntax checking, refactoring, inline debugging, autocomplete, etc.
Would it make more sense to develop a developing environment that makes
disabled developers better at coding, with whatever features would make their
experience better?

It would probably be easier to get a disabled developer to use your editor
than to get a disabled developer to use your language. From what I can gather,
it's hard enough to get employment as it is for them (maybe they can only work
remote, or maybe they can be physically in the office but they're blind). I'm
not sure if they have the luxury of being able to choose what language they
get to use. But I'm sure their employers would allow them to use the IDE &
tooling that works for them so long as they output code that fits the company
stack.

------
cteague
Thinking about disabilities that are not necessarily physical such as
dyslexia, adhd, and other things that affect cognition--I would say an optimal
programming language should be as easy to understand and read as possible.
This would mean choosing the style of the language and the syntax so that it
optimizes for readability. Also, removing the amount of the context someone
needs to understand a piece of code. Perhaps this could be accomplished by
strict enforcement of modularity and things like auto-generated or required
documentation so that interfaces can be understood without diving into them if
possible.

Obviously, inherent to programming is diving deep into chained function calls
and managing all those levels in abstraction in one's mind. However, for
someone with a limited working memory for whatever reason--adhd, depression,
chronic pain, anxiety, headaches and more--having this minimized as much as
possible would be a lifesaver.

------
manch23
Forgive me if I missed it, but I don’t believe I saw any mentions of ruby in
this thread.

I feel like the English like syntax and use of keywords instead of symbols
would be very beneficial for people with disabilities.

I guess python is in a similar vein, but ruby doesn’t rely on white space for
its blocks, which I think is a real plus.

------
picometer
A while back I was experimenting with something akin to "syntax highlighting"
with sound instead of color. The idea is to play different tones/noises
depending on where your cursor is located in your code. Rough proof of concept
that you can try out:
[http://marycourtland.github.io/AuralJS/](http://marycourtland.github.io/AuralJS/)

This was just a fun experiment - I'm not blind or visually impaired - but I
imagine that the concept could useful for programmers who depend on screen
readers. It could be simplified as well; e.g., adjust the pitch or timbre of
the voice depending on the nesting level of code.

------
ndarilek
Hey, kudos to you for thinking about this! Background: I'm totally blind, have
programmed for nearly 3 decades, kind of do the in and out of half a dozen
languages thing these days. Today's favorites are Rust anywhere I can get away
with it, Python because it runs in places where I need it (Home Assistant,
Mycroft, etc.) and JavaScript because if I hold my nose and don't think too
much about the atrocities I'm committing, I can run the same or similar code
in various form factors. I'll try to give a few pointers. Note that these are
specific to blindness, and specific to me. I don't claim to speak for the
disabled population as a whole, as we're kind of a grab bag.

1\. Indentation: Pretty much a solved problem at this point. If I were reading
Python code line-by-line, my editor might speak something like (not sure if my
newlines will make it, but imagine them where they should be): def
hello(world): 4 spaces print("Hello, world.") 4 spaces 1 tab 4 spaces
print("What was I thinking when I indented this line?")

So I wouldn't worry too much about that. I've never had issues with an
indentation-based language, and anyone blind who does likely just needs to
change their tooling a bit. This is usually just a checkbox in the screen
reader settings, so doesn't even usually require an editor/IDE change.

2\. Avoid crazy symbols. Scala gave me some grief with this, with every
library author having method names like %^&@^$# because I assume that set of
symbols looks like performHttpRequest(...) in some visual way. I exaggerate a
bit. Only a bit. Note that operator overloading is fine, at least from an
accessibility perspective. It's when people decide that a series of connected
punctuation symbols evokes the idea of making an HTTP request or opening an
Option that I start to get annoyed.

3\. Create good command line tooling. Rust has this nailed. I like how Rust's
own installer just uses rustup under the hood, or at least I think it does,
and every blog post advertising a new component also includes the rustup
incantations to grab it. I assume the editor interfaces are as nice or nearly
so. I guess the takeaway is, package your language installation tooling in a
library so you can invoke it from the CLI, editor plugins, etc.

4\. Put error messages at the bottom of stacktraces rather than the top.
Python does this right, and everyone else gets it wrong[1]. Say you're running
a compiler from your command line. You get an error, and your cursor lands on
the input area, ready for a new command. As a screen reader user, you discover
that error by entering your window's review mode and moving up. With
JavaScript, Rust, and just about everything else, I have to arrow through the
callstack in reverse as I move up the screen to the line containing the error.
Python puts this error last, near the input cursor, so all you're doing is
arrowing up a couple lines. It's a few seconds per error, but can add up
immensely over the course of a day. NPM, infuriatingly, shows the error,
followed by disclaimer text that the error isn't in NPM, then barfs up an NPM
error just to confuse things. So any JS package I use that uses NPM for its
scripting requires arrowing back through _2_ stacktraces to find the original
error. It's enough to drive me to drink.

I can probably come up with more, but I haven't finished my coffee yet.
Perhaps that's a good thing...

1\. Right and wrong are of course subjective. This is just one blind dude's
opinion, take it for what it's worth.

~~~
currymj
Are Unicode characters a problem for the tools you use?

For example, some languages will let you use λ instead of lambda. Or when
trying to define the logistic function, I sometimes find myself writing

    
    
      σ(x) = 1.0 / (1.0 * exp(-x))
    

Or the Julia language has ≈, which tests if two floating point numbers are
approximately equal. Visually, this is a reasonable symbol, it's not like one
of the weird functional programming spaceship operators. But I have no idea
what a screen reader would read.

Sometimes this sort of thing lets code correspond almost exactly to the
notation in papers. It is a minor aesthetic improvement, but if it breaks
screen readers and other tools I'd rather just write out "sigma" or "lambda".

~~~
ndarilek
My screen reader, Orca under Linux, read those as "sigma" and "almost equal
to." So I suppose those work, though I'd have to hit Google to find out how to
type them. :)

~~~
mwcampbell
The NVDA screen reader for Windows also reads these symbols. So it looks like
they're not a problem.

------
mcphage
I'll be honest, I don't have any answers for you—but this is a really
interesting question, and I'm looking forward to reading what other HN readers
suggest.

------
SilasX
>Making whitespace-sensitive syntax, like in Python & Haskell, optional
syntactic sugar for explicit brackets & separators.

That shouldn't matter with an IDE or plugin. If static analysis can identify
the blocks -- and it has to! -- the screen reader can just read it as if it
had your preferred block notation rather than noting the whitespace.

~~~
simion314
You also need to read coding books, documentation examples and webpages, so
having to use an IDE is not the best solution.

~~~
SilasX
Seems like the real problem is the lack of interoperability between a special
coding parser and arbitrary snippets of online code.

------
fnordfnordfnord
I don't have any specific advice here but I can share that I one worked with a
physics professor who is quadrupelegic and he is one of the fastest most
productive programmers I have ever seen. He worked in C and C±+ mostly, and
typed with a stick which he held in his mouth. Don't underestimate peoples'
adaptability.

------
KevanM
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.

------
eggxbox8
Bootstrap is doing some work in this space:
[https://www.bootstrapworld.org/blog/accessibility/User-
Inter...](https://www.bootstrapworld.org/blog/accessibility/User-Interface-
REPL.shtml)

------
jdbdline
i recently broke my two fingers on my right hand and could only code with the
left hand (i am right handed) would have loved intellegint auto complete. And
speach to text interface. That would be cool

------
stephenwithav
#3 is a good start.

I can't really think of anything that would greatly enhance my current
Linux/tmux/emacs setup.

------
_nalply
What about Deaf programmers like me? How are they going to survive
interviewing?

------
reacweb
Maybe we should train to code without screen: just a keyboard and a headset.

~~~
hluska
I think this is a very good idea. Several years ago, I learned how to browse
the web with a keyboard and screen reader. Honestly, picking up that skill
made me a noticeably better software developer. Prior to that experience, I
had a vague idea about accessibility, but for the most part, it was just about
checking a box when I was going for certain types of contracts. But, once I
got into the screen reader flow, all of my formerly vague ideas became really
solid concepts. I build much more accessible applications now because of this
knowledge.

------
miki123211
1\. Do indentation right. One of the hardest things to do with a screen reader
is indenting to a symbol. If we have a statement that doesn't fit on a line,
it's much easier to increase the indentation by one level than to make the
line start at the position where a symbol like ( is. The screen reader can
tell you how many spaces of indentation you have, but figuring out where that
symbol actually is and if it looks good is a real pain. This also applies to
other situations where the exact number of whitespace matters like making
struct declarations in c or go into a table, where one column is the name, one
is the type and one is the comment, and spaces are used for alignment. If you
really care about screen readers, I think tabs are a better idea for
indentation, I feel they're a bit easier to use, though that may just be my
preference. One language that got this horribly wrong is python, four space
indentation and a lot of starting the next line exactly below a particular
character on the previous one. A language that really got this right is go.
They use tab indentation and they have that amazing tool called go fmt that
basically does all the work for you. It basically formats your code in the
standard go way. Yes, go aligns structs with spaces but I don't particularly
care in that situation. I never use that convention in my code, I just run go
fmt before committing and I'm sure everything looks right. In my opinion,
alignment with spaces is the hardest thing to do when developing with a screen
reader and it's really hard to avoid when your code convention requires it and
you don't have a tool that does it for you. 2\. Make error messages textual. A
message like error at line 10(25), invalid syntax where 25 is the column is
much easier to read than error at line 10, followed by the line with a ^ under
the character in column 25. Another thing Python does wrong.

3\. If you make a GUI framework, use native controls. Screen readers aren't
magical pieces of software that do their things using arcane spells, to read
anything, they actually need to get the information to read. To do this, they
use operating system APIs. When an application uses native controls, it
exposes all the needed information through those APIs and a screen reader can
get it easily. If an application has it's own GUI toolkit, it's own
representation of controls that doesn't correspond to the OS notions of a
control and draws on the screen directly, the screen reader doesn't know
anything at all. This is the case with i.e. GTK on windows. For a long time,
this was also the case with Flash, Java and QT. 4\. screen reader users
generally prefer words over symbols (controversial, some might disagree).
Symbols are nice for sighted users because they take less space on the screen
and are faster to read, but for screen reader users they are not. Lua's "if a
less than 1 then print quote this is a test quote end" reads much more
naturally than go's "if a less than 1 left brace fmt dot print l n left paren
quote this is a test quote right paren right brace". There's a reason why
blind programmers like lua and ruby. 5\. Very hard to do right, but one of the
most annoying thing for me is to deal with various messages in the console. If
it's a web table, you can do two columns, timestamp and message, and a blind
user will know it's a table and be able to navigate only in the second column.
If it's console output, you can separate them visually, sighted users will
just glance over the timestamps but blind users actually need to hear them
before hearing the message. Imagine you need to listen through "two tousant
eighteen colon eleven colon zero nine seven colon fourty five colon three
comma 7520, /cmd/frontend/main.go:19: server started" before each message
instead of just "server started". That's the sad reality for most blind people
dealing with logs and messages that contain long paths etc. I don't know if
that can even be done right without hiding the info alltogether, as it's not
possible for a blind person to navigate a table in the console, but this is
something that should be taken into consideration.

------
austincheney
Accessibility is closely tied to portability. As a minimalist its not about
what you can add but rather what you can take away and ensuring everybody
understands reading the code with minimal effort everywhere.

A more accessible and portable language is one that eliminates overloading and
redundancy. Everything in the syntax and expression is deliberate and its not
open to various subjective forms of reasoning.

Eliminate white space as syntax. Beauty is subjective, but it isn't
necessarily accessible, and it certainly isn't automatically simple. White
space as syntax is common in nearly all languages. Even in Java there is white
space to separate keywords. White space elimination allows any manner of
visual expression and beautification of the language. It also prevents
corruption of the code over the wire due to reformatting of corrupting user-
agents and OSes that have different line endings. One form of corruption is
when a token is shifted, due to different reasoning of line termination, onto
a previous line terminated by a line comment.

Eliminate operator overloading. In JavaScript the plus character could mean
addition, or string concatenation, or type coercion, or other weird things.
The plus character could be a single character operator or the dreaded _++_
which could mean post-increment or pre-increment. In JavaScript the forward
slash could mean division or regular expression. For a blind person reading
the code as characters or tokens this kind of overloading is unnecessarily
confusing bullshit.

Conversely JavaScript has two different syntax forms for assignment. The
common form of assigning is using a single equals character. In object
literals a colon is used for assignment. This is stupid and looks completely
different from the algebra on which equivalent logic is based. Make the colon
character the character of all assignment. This leaves the single equals
character free for comparisons. If the language imposes a strong/static type
system there will be no need for double or triple character comparison
operators.

I would invoke a strong/static type system. This allows error detection very
early which reduces testing time and jumping between application environments.

I would design the language in such a way that it encourages code in
structures. It is easier to follow code when it reads similar to its flow
control at execution time. In this regard I would write the syntax such that
it encourages containment, nesting, function as organizational models that can
be nested, and design everything around primitive data structures.

I am not a fan of OOP programming where the application is easier to
write/expand than to debug or read. OOP constructs tend to be convention
heavy, keyword heavy, and syntax heavy. Functional/structured languages allow
the deliberate organization of its pieces to do much of the heavy lifting as
opposed to referenced or logical organizations.

Don't worry about superficial tooling support. Solve the language design
problems, the hard problems first. The helpful tooling bits will be easy if
you have nailed the hard decisions and produced something with clarity,
simplicity, and deliberation.

~~~
kbp
I don't understand what most of these points have to do with accessibility.
Why would a blind person have more trouble with the fact that "x + y" might be
addition or string concatenation than a sighted person? Why would compile-time
type errors be more useful to a disabled person? And so on. It just feels like
your opinions on a lot of language design holy wars where disabled people are
just as likely to disagree with you as anyone else.

> Don't worry about superficial tooling support. Solve the language design
> problems, the hard problems first.

That's mostly what people have been doing for the last most-of-a-century, and
it's led to a lot of software being much harder to use for disabled people.

~~~
austincheney
The nature of accessibility is in solving universal access problems. It
includes blind people but isn’t limited to blind people. One of the largest
areas of accessibility is solving for cognitive impairments.

The classic example is wheel chair ramps. Who benefits from those? People who
have bad knees, people with strollers, people with heavy roller bags. The ramp
was installed for wheelchairs but everybody benefits. If the solution were
limited only to wheelchairs almost nobody would use it. It would just be in
the way and be more of a problem than a solution.

If you are only solving for blindness you don’t really understand
accessibility and are just in the way.

~~~
kbp
You misunderstood. I only used blindness for the specific example where you
used blindness (the only specific example of affecting someone with a
disability that you gave; why would that be harder for a blind person?). Most
of your points didn't explain how they related to accessibility, they just
said your way was easier and better without explaining how or to whom. That's
what I was asking.

~~~
austincheney
Many people conflate access to aesthetics. There is a difference between
actual ease of access and perceived elegancy resultant from vane conditions.

Specifically regarding programming languages the primary concern is parsing,
whether that parsing is from software or people reading code.

As a person who has spent 10 years writing language parsers and code
beautifiers the vane notions of what a language should look like are highly
subjective and not incredibly beneficial. The mechanics and syntax of a
language are far more important for understanding what code says very quickly.
Like with natural written language elimination of ambiguities and redundant
meanings speeds learning and reading which has second and third order
consequences for the simplicity of tool design.

------
caymanjim
Avoid Perl 6 and its horrifying Unicode keywords and operators.

~~~
lizmat
FUD. Unicode keywords and operators in Perl 6 are __optional __. For each
unicode version, an ASCII alternative is also available.

