Introduction

Coding with eyes closed is for people who recently became blind or visually impaired and would like to code. This is not a tutorial on how to code. You already know how to write a program, but you're too inexperienced with coding with screen readers to do so. The goal of this book is to get you up and running again, and hopefully get back to work.

Coding with eyes closed is possible. It is hard, really hard, but not impossible. I've made a website using typescript and a reproducible build system with Nix, CI/CD with github actions and merged pull requests in various open source projects all without reading a single character. Everything with only the use of text to speech and a little bit of braille.

It is a challenging journey, and you may need to adjust your expectations about your skills. You may be the best programmer on earth, but in the first few months, your inexperience with screen readers will limit you in creating the most beautiful applications. I believe that if you like to code, you can do this.

This book is meant for people who depend on screen reader and text-to-speech (TTS) technology. It has useful elements for people with partial sight, but it is mostly meant for people who have little to no vision. I believe that how people with partial sight use technology comes closer to how a visual person would use technology. If you come from a sighted world and now depend on TTS, programming is way harder than working with magnifications for example.

I can now use my sight with magnifications., but programming with little to no sight made me a better programmer, because I had to be really careful where I had to put my functions, which made me better at thinking about separation of concern.

This book is highly opinionated. I will give advice based on my own experiences with my use of TTS technology. I had little to no sight between 2021 and 2023. The accessibility field is moving fast, and my recommendations regarding tooling will some day be outdated. It contains recommendations about tooling, but also tips that will still be useful 20 years from now. The book also contains exercises, to get you up and running.

How you should read this book.

You have to learn a lot of things when you lose your sight practically and emotionally. That is why I made a very efficient way to read this book.

To follow the fastest path possible to code with eyes closed, go to the cheat sheet section and read it and follow the advice. All the claims are linked to chapters that explain it in more detail, so you can read exactly how much you need. After reading the cheat sheet, you should try the exercises.

If you have sight but you want to learn how you can make your infrastructure more accessible for blind programmers, I recommend reading the language chapter and the cheat sheet.

Of course, you can also read this book from beginning to end.

This book gives advice, and every good coder experiments with tooling and languages to find a way that works best for them. That is no different for coders with their eyes closed. Experiment on your journey but not too much. Else you will waste your time.

Getting help

Please ask your questions on the matrix server

#coding-with-eyes-closed:matrix.org

Supporting this project

There are a few ways you can support this project.

  • Opening a pull request or issue. English is not my native language and I have dyslexia. If you find a spell mistake, please submit an issue or pull request on the repo.
  • Star the repository. This way more people can find the book.
  • Helping other people on the matrix server

Motivation

I wrote my first line of code when I was about 11 years old. I had a great interest in ios app development and making games in unity. Game development was nice because I could make the art, music and the code by myself.

But this all changed about two years ago. I was diagnosed with Leber Hereditary Optic Neuropathy (LHON). This is a genetic disease which brought my vision from 100% to 1% in 6 months. I was 16 and I had to do things differently. I could not see the screen anymore so I turned on VoiceOver, was handed a braille display, learned braille and started using my mac with VoiceOver.

Mobility, traveling with public transport, and navigating technology were all straightforward for me. But coding with closed eyes is hard. Reading one line at a time is a big limitation for example. I knew that it was possible, because I saw all sorts of people coding with their eyes closed on the internet. But I could not find a good guide on how to do it.

But then I spoke someone who was completely blind and made websites with HTML and he did the styling with css without sight. He said to me that I should just practice and try to make very small stuff. Hello world with HTML. It was really hard but it felt so good when I succeeded. I made the challenges harder and harder to the point that I've made a servo motor turn via an arduino, and connecting all the wires myself.

I can program now, but it took me a long time. More than a year before I could call myself a programmer. I want a book that you can read to get up and running again as fast as possible. So quicker than a year. I also want it to be accessible for everyone. No money or rich institute needed.

I was glad of open source tools on my journey to this point and this is a way of saying thank you for all the accessible tools.

So, shall we start?

Where to start?

The fact that you're reading this book is probably because of an accident or a disease. I am sorry for you. Everything is going to be just fine. There is a lot possible and there are a lot of accessible tools. I will talk briefly about operating systems, screen readers and braille. Ready? Let's go!

Operating systems

You probably already have a favorite operating system, that's fine. I am going to give you advice from an accessibility standpoint.

If you are starting out, you are learning a lot. My advice is to take the easiest route and switch when you need it for a project. Linux is useful for a whole lot of reasons. Fast, a good shell, open-source. Just to name a few. But most visually impaired people use windows. I am not talking about developers, just people in general, the people who do not know that they are even using windows. If something is wrong with an app, you will not be alone on windows.

If you are on arch linux unstable on arm64 with a vim-based screen reader, a tiling window manager and you cannot read your email anymore... Good luck, You have to figure it out yourself.

My advice is to use the most popular option for VIP (visually impaired person/people). If you become better at using your tools, you can consider switching to linux for example.

First you should be able to write a program. If you succeed, consider switching tools.

So back to operating systems, here's a overview of what I think of each operating system from an accessibility standpoint.

Windows

Pros
  • a lot of users
  • most applications are accessible out of the box
  • popular screen reader options
Cons
  • Bad shell
  • Blue screens
  • Closed source

MacOS

Pros
  • VoiceOver is fast to use and easy to pick up, especially if you know how VoiceOver works on iPhone.
  • Almost all apple products are accessible
  • A terminal that works with VoiceOver
  • VoiceOver is on every mac
Cons
  • you need a mac
  • closed source
Linux

There are a lot of linux distributions, some of which focus on accessibility. I've never used a linux distribution with no sight, because I could not set it up on my own.

If you want to use linux, do not dual boot. Start with a virtual machine in an operating system that you can use.

This way you can learn tools in the VM and use your browser outside the VM for reading documentation for example. When you are ready to use linux, you can dual boot if you wish.

You can also ssh into a virtual machine. I believe linux has the best tooling for developers. Sadly it is hard to use from an accessibility standpoint.

What do I use?

I use MacOS with Nix darwin as my package manager and build system. VoiceOver is easy to pickup and I have a terminal.

I recommend starting out with windows or if you can afford it MacOS. You can always try Linux after you wrote your first application with your eyes closed.

Next up, lets talk about screen readers!

Screen readers

Feel free to skip parts if you already use a screen reader.

What's a screen reader?

According to the definition of wikipedia:

"A screen reader is a form of assistive technology that renders text and image content as speech or braille output."

If you don't like the voices of a screen reader, you still need one because it is also used for braille.

Here are some sources if you want to learn more about screen readers:

I don't need a screen reader

Screen readers are extremely useful. Even if you have enough sight to read large text. It is useful. Here is why. Visually impaired users do not only have an problem with their eyes, they have a problem with energy through out the day. You need twice as much energy to perform a task than visual people. If you want to be productive, you need to optimize as much as possible to not only be faster, but to save energy so you can invest it in the right type of activity. When I am coding, I need my energy for coming up with a good, elegant and scalable solution. That energy should not go in reading text on your screen.

Now that I have more sight, I use large text in my editor, but I still read documentation with a screen reader because it costs less energy.

If you are visually impaired, learn how to use a screen reader. It is a bit of an investment, but you earn it back with having more energy for solving problems.

Give me a screen reader!

First learn a screen reader on a smartphone. Why? Smartphones have simple user-interfaces. Navigating apps on a smartphone is relatively easy. This way, you can get used to the idea of navigating based on sounds instead of light.

If you learned how to use your smartphone without sight, learn a screen reader for the desktop. Desktop screen readers are more complex, but once you learned a mobile screen reader, you can make the switch!

What desktop screen reader?

Feel free to experiment, you'll have to figure out what works for you. Here are my quick recommendations.

Windows

If you are on windows, use NVDA. It is fast, open source and free. You have other options, but they are slow and too complex and crash a lot. NVDA is not only free, but it is better then the payed options.

Mac

I like VoiceOver the most. Navigating is fast, you do not have to install anything and grouping elements makes finding the right button very easy.

If you want to learn VoiceOver for mac, press CMD F5, follow the built-in tutorial and read the VoiceOver user guide

Linux

On linux, you have orca that you have to use with GNOME. I do not recommend this. If you have to use linux, SSH into a virtual machine and use the MacOS or windows screen reader.

Do I need braille to code?

Short answer no. You can do everything with just a laptop and a screen reader.

I like braille. You can feel every single character and their is something about braille that feels magical. feeling git add README.md in the terminal is really cool. Reading braille comes more close to reading visual character then hearing words.

Braille is useful for solving syntax errors because you can feel if their is a mismatched curly bracket. It made be more experimental with programming languages, for example I want the entire definition of a function to be on one line so it could fit on my braille display, so I chose haskell to accomplish that.

What is a braille display?

A braille display, for people who do not know is a device that have little points that can move up and down. This way, the characters are not static but dynamic. Content can change based on the context of your application. A tipple braille display contains about 40 characters. You can compare regular braille and a braille display to a poster and a monitor. A poster is static, but a monitor can change 60 times a second. A note in braille is static, but you can change the content of the braille display with buttons to go the next line.

But sadly, braille displays are expensive. A braille display costs between 3000 and 5000 euro's as am typing this in 2023. My government gave me a braille display because I live in a country where they provide good care for people with a handicap. If your government is willing to give braille displays to visually impaired people, please make sure you get your hands on it, it is fun to learn it braille can be very relaxing when you're reading a book.

Why braille makes me less productive

I use braille every now and then, reading books for example, but I do not use braille for coding because it makes me less productive. With screen readers, you can hear words insanely fast. I believe I can read my email twice as fast then how visual people would read their email.

From the people I spoke, including someone who only used braille and did not use any TTS technology where as fast as someone with sight or slower. Moving your hands between the braille display and the keyboard is slow. Yes you can type on braille displays but it is not as fast as typing with 10 fingers.

You cannot code with your laptop sitting on your lap, because you need your braille display. This seems as something that is not important but I like to code in the train for example or solving a advent of code puzzle in the living room.

Braille is slow. Not only reading braille but moving your hands between the braille display and the keyboard. Depending on a braille display is annoying too and it is expensive. You do not need braille to code.

Which tools are accessible?

We will talk about tools that help you write code. The goal of this chapter is to optimize as much as possible with your tooling to regain speed.

This chapters covers terminals, editors and websites. Lets get into it.

Goodbye terminal life

This chapter is meant for people who depend on TTS technology. Terminals are great for people with partial sight. Every TUI (terminal user interface) has maximum contrast. It's just a grid of characters. If hav partial sight please keep using your terminal.

What is the problem with terminals?

With shells like bash or zsh, you type a string and it returns a string. You may think that that is a good thing. The only thing that is left is to read with a speech synthesizer that string and your done.

Sadly for us, people can very creative with just a grid of characters.

Problem 1: We cannot filter strings precise enough to work fast with terminals

Neofetch is a TUI that prints information about your system. On the left a ASCII art logo of your operating system and on the right information about your system. This is great for people with sight but for people like us that logo is distracting. If that string is read to us, we hear something like:

OS: macOS 13.4.1 22F82 arm64:MMMMMMMMMMMMMMMMMMMMMMMM: DE: Aqua .MMMMMMMMMMMMMMMMMMMMMMMMX. WM: Quartz Compositor kMMMMMMMMMMMMMMMMMMMMMMMMWd.

There is a lot of garbage in this string and we do not know how to filter it.

Here is another example: we want to know the file permissions of a file called zellij.md. We know it is in our home directory so we run the the following command:

ls -la

First all other files are read before the file that starts with the z is read. Now we have to wait and here all other permissions before we here the file we need.

I believe this is fixable by adding flags to the ls commands to filter it or piping the output in another cli that can filter only that specific line but it costs a lot of time because you need to think how you are going to filter that string to find what you need. Visual people would only do that with strings that are longer then 100 lines, but we need a filter with 10 and that is time consuming.

You can find a workaround but it does not feel natural.

Problem 2: Graphical terminal user interfaces

We also have sort of graphical applications for the terminal.

Lazygit for example has a part on the screen to show which files are staged for commits, a other view for on which branch you're on, pop-up dialogs for selecting a remote and a view showing the changes made for each file. All in 1 single view. A screen reader has no idea what is going on here because a screen reader only sees a grid of text.

Helix is a vim-like editor written in rust. It is a great editor but not for people who depend on screen readers. A screen reader has no idea when it is in normal mode and in insert mode so it has no idea when a j keypress should read the next line or if the user is typing joyful in insert mode.

These are examples to illustrate the problem with terminals for screen reader users. Helix and lazygit are great tools that I personally use everyday, but it is not accessible for the blind.

Problem 3: Finding a terminal

Most terminals do not integrate so well with your screen reader. I tried to use git bash with nvda on windows but it was just a mess. I could barely hear contents of a small file with cat.

The default console that comes with gnome did not read the output with the default gnome screen reader called orca.

Kitty does not read text with VoiceOver on MacOS nor with orca on NixOS.

iTerm worked pretty good on Mac, but navigating with a braille display was harder.

The best experience I had with terminals and screen readers was VoiceOver on MacOS with the default MacOS terminal.

How can we fix this?

I really hope that terminals we be just as accessible as gui's. The best thing to do for now is avoid the terminal as much as possible.

How to avoid the terminal?

I will cover the basic stuff here. A terminal is so powerful that you should come up with your own ideas for you specific situation. You will never be able to do everything a programmer with sight can do. That is why it is not a bad thing to ask someone if you cannot do something in the terminal.

1. Navigating files

Don't use ls, cd, cat or less. Use a graphical interface such as finder or explorer.

2. Your editor

This part was pretty emotional for me, but you should not use vim. I will cover which editor you should use in another chapter.

3. git

Don't worry, we still use git, but avoid the cli.

Most graphical IDE's come s with integrated git functionality. Those buttons have labels so you can do git like operations with the cli.

4. Write scripts.

If you have common tasks in the terminal that are hard. Automate it.

I hope terminals will become accessible in the future, but this is the best option we have.

Next up, we will talk about editors.

What's the most accessible editor?

We learned that the terminal is not as accessible as we hoped. The best thing to do is look for a graphical application.

Start basic. Just something that can modify a .txt file. Why? Because reading code is in the beginning hard enough. It can be microsoft Word if that is something you're used to. Just paste a piece of code into a editor you like and try to understand what is going on. Make sure that line-wrap is turned off. It does not matter if the text is not visible because we hear the text.

When people ask to me what it is like to code with eyes closed, I tell them that it is like using your IDE but only seeing 1 line at a time. This seems almost impossible but believe me, you can be productive with this limitation.

Install a few different editors and experiment along with the exercises later on in the book.

Your editor should have at least the following:

  • Accessible integration with language servers.
  • Many shortcuts
  • Integration with git

I will cover these three aspects in detail.

Accessible integration with language servers

What is LSP? A quote form the (microsoft lsp website).

"The Language Server Protocol (LSP) defines the protocol used between an editor or IDE and a language server that provides language features like auto complete, go to definition, find all references etc. The goal of the Language Server Index Format (LSIF, pronounced like "else if") is to support rich code navigation in development tools or a Web UI without needing a local copy of the source code."

It could also be an editor that doesn't implement LSP but provide the same features such as auto-complete. But to keep it simple, I will refer it as LSP features.

A language server is extra important to us. Why? Because we only see 1 line at a time and it takes more time to understand what is happening on that line.

We want to be as productive as possible so we need to navigate to the right line as fast as possible. Language servers helps you do that.

Let's say you have an error and no language server. You have to read the error message of the compiler, which is most of the time in the terminal. Then you know the error, and you need to navigate to the right line in the right file. That costs time.

With accessible integration of LSP, you can view a list of all your errors and then click on it to navigate to the right line in the right file. This is way faster.

If you are reading code and you want to know more about a function, you can go to the definition with one shortcut and you do not have to navigate through tons of files.

Language servers are great, the productivity boost that you earn is way higher for visually impaired people then for people with sight. So find a editor that implements the protocol in a accessible way.

Many shortcuts

Most coders with sight use the mouse to perform certain tasks. They click on the commit button, then on the textfield to compose a commit message, click commit and finally click push. Performing these tasks takes more time for visually impaired people. Finding those buttons with a screen reader can be a bit tedious.

This tip does not only apply to coding but for every workflow you have: Learn many many shortcuts. Shortcuts are so important, what I noticed from my experience in general is that shortcuts are more important then if a button is labelled. With an unlabelled button, you have to figure out yourself what the button does. But with a shortcut, you can perform the action of that button without even thinking about it.

If I know that the file I am searching is called main.rs, then I should never go throw a file tree explorer that would take me 3 minutes. I need a shortcut in this situation to quickly filter files on name so I can go to that specific file.

Finding visual buttons costs time for us so avoid it as much as possible. Do not throw your IDE in the bin pure because their are some unlabelled images and buttons. The shortcuts are important.

Integration with git

Git is integrated in most modern editors and most editors provide good shortcuts so you can commit your changes fast. This is useful because it is hard for visually impaired users to interact with the git CLI.

If you find an editor that you like but it does not integrate well with git, you can always use a stand olen application to interact with git such as github desktop.

So, where shall I start?

Experiment with different editors to see which one works best for you. I found that popular software is most of the time accessible too.

When I depended on TTS technology, I was very happy with vscodium. Github desktop was also handy for me. It is graphical and had many shortcuts. I wrote this in 2023 so there is a good chance if you're reading this that these products are not the most accessible anymore. So experiment with different editors, going from most popular to less popular.

Next up, we will learn more about searching for information on the web.

Navigating websites and recommendations

Finding information can be hard without sight. Here are a few quick tips to make it more easy.

1. Avoid searching for information

Ehhhhh what?! Yeah, RTFM

The difference between a good and a bad coder is that a good coder first learn a tool by reading the manual BEFORE they use the tool. Look, you can be a smart person and figure it all out yourself but if someone else figured it out before you did and wrote a book or manual, it would be stupid not to read that manual. Yes, of course it can be fun en educative but when it comes to speed, someone who reads a manual learns a tool way faster then someone that googles everything together. If there are libraries full of books that explain how you can build a house that lasts for decades, it would be really dum to just start building without reading a book and hope that it will work.

"No, I am a learning by doing person so let me alone, I do it my way."

You should have a basis before you learn-by-doing.

This sounds very basic like yeah yeah I already know this stuff lets move on but I see so many people doing the wrong stuff.

Lets say you want to learn how css works. Many people try to change the background color, changing the font and they make a piece of text bold. Then they think, Ohh this is going quite well! Lets make a website!

But then they should center a image in a div and they are googeling from sunrise to sunset combining all sorts of copy pasta answers from stack overflow without knowing what actually happens or what it means.

This is what a lot of people do, coders laugh about a how to center div css joke and they go on with their stupid google everything together mentality.

If you want to learn css, read a book about it and then learn by doing.

Many people say, ohhhh rust is so hard what is a lifetime? Then they google what lifetimes are and the answer uses terminology from other rust concepts that they do not understand and as a solution copy the suggestion from the compiler and hope that it works without understanding what it means that they've copied into their project.

Rust is easy if you have the discipline to just read a book about the rust language.

If you have the feeling that I am talking to you, don't worry, every good programmer learned this at some point so if you are learning this now, enjoy! You can be way more productive.

The benefits of reading the manual are:

  • You work way faster.
  • You actually know how something works.
  • You do not have to visit all sorts of websites with cookies that are harder to navigate with a screen reader.

2. Don't use google

If google works for you that is fine. I like duckduckgo way more from an accessibility standpoint.

This is because duckduckgo most of the time only gives a list of links. It is easier to navigate that with a screen reader. The only thing that you have to do is next heading and previous heading to navigate through the list

Google gives a fragment of a youtube video as its first result and advertisements that have nothing to do with your search.

But the best feature from an accessibility standpoint are bangs.

If you want to search for coding with eyes closed on github. Normally you would go to github.com, navigate for the search text field, enter your query and go through the search results.

With duckduckgo, you can enter this query:

  !gh coding with eyes closed

If you want to learn more about ISO_8691, enter this query:

  !w iso 8601

If you want to learn more about a crate on docs.rs, clap for example, enter this query:

  !docsrs clap

How editors are way faster with shortcuts, duckduckgo is way faster with bangs. Bangs are shortcuts for the search-engine.

3. Consider AI-based chat bots

Chat bots such as chat gpt can boost your productivity significantly. Chat bots can scrape information from websites and format it in such a way that it can save you many minutes otherwise spent on googling.

Those where my tips. We've covered a lot. The next chapter is the last technical chapter, we will talk about programming languages. Ready? Lets go!

What language should I use?

This is the most important chapter in the book. These ideas are useful for blind and visually impaired coders.

We will learn how we can choose the right language so the compiler can help us the best.

The compiler is your sight

This chapter is written all around 1 idea. The compiler is your sight.

I will explain why the compiler is so important if you're coding with eyes closed.

We have a big limitation. We can only read 1 line at a time. If you have partial sight maybe 3 lines at a time. This is what makes coding with eyes closed very hard. The trick is to not use that sight to search for errors. The compiler should search for errors.

This idea is not new at all, but many coders do not listen to this advice at all. As I am writing this, the two most popular programming languages are javascript and python. Neither of these languages implement this idea well enough. Javascript says so many times stuff like object is undefined or null is undefined. The compiler just has no idea what kind of mistake the coder made.

Because of this, people have to search for errors instead of the compiler. For people with sight, this is frustrating and it makes people less productive. But having to search for those errors without sight is insanely hard.

It could be something so small as a semicolon. People with sight can look at each line very fast to find where the semicolon is missing. For us it takes time, way too much time.

If we use a language that has a good strict compiler that gives good error messages, we do not have to search for errors because the compiler already found them. A strict compiler tells you where the semicolon is missing, why that screws up the rest of the program and a suggestion where you should put the semicolon to fix it.

With a bad compiler, you can maybe be 30% productive compared to a sighted coder. But with a strict compiler, you can be 90% productive compared to a sighted coder.

Bad languages are not just a bad language, we cannot make scalable products because of our sight.

That doesn't mean people without sight cannot code, they can only code in languages that have strict compilers.

We will first talk about type systems. One of the most important aspects of a programming language.

Why dynamic types are even worse for someone with an visual impairment

We will look at type systems. First I'll explain what the differences are between a dynamic type system and a static type system and afterwards why you should prefer a static type system over a dynamic type system.

What's the difference?

With a dynamic type system, types can change over lifetime. With a static type system, types are decided at compile time. They cannot change over lifetime.

Here is an example so you can see how the types behavior differently in different languages.

Here is an example in python. Python has a dynamic type system.

# x is a string here
x ="this is a string"
  
# x is a a integer here
x = 42

Note that the types change here, this is different from shadowing in rust

So as we see, a was first an integer and now it's a string. This compiles as expected because python has dynamic types.

Now we will look how a static type system will happen if we wrote this in Rust. Rust has a static type system.

  fn main() {
      let mut x = 5;
      x = "hello";
      println!("{}", x);
  }

Note: mut means mutable, so the value can change

This code does not compile, because x is first a integer but then tries to be a string. This means that the types change and the rust compiler does not allow that behavior.

The compiler shows the following error:

error[E0308]: mismatched types
 --> src/main.rs:3:9
  |
2 |     let mut x = 5;
  |                 - expected due to this value
3 |     x = "hello";
  |         ^^^^^^^ expected integer, found `&str`

We can change the value of x, but the value should change within the range of the integer type. Here is an example:

fn main() {
    let mut x = 5;
    x = 42;
    println!("{}", x);
}

This program will compile just fine and print 42 to the console.

So as we saw, a static type system does not mean values cannot change, types cannot change.

Now I will explain why this difference is important for visually impaired coders.

Why static is better then dynamic

Here is a quote from the type system wikipedia page

"Type systems are often specified as part of programming languages and built into interpreters and compilers, although the type system of a language can be extended by optional tools that perform added checks using the language's original type syntax and grammar. The main purpose of a type system in a programming language is to reduce possibilities for bugs in computer programs due to type errors.[2] The given type system in question determines what constitutes a type error, but in general, the aim is to prevent operations expecting a certain kind of value from being used with values of which that operation does not make sense (validity errors)."

So, type systems help us find bugs and they make sure we use our stuff in a correct way. This is useful. We want a compiler that can assist us well because we can only see one line at a time. We do not want a blind compiler.

Static type systems are way better and finding bugs and assisting the coder then dynamic type systems. The compiler can under stand better how types should behave and types can only change if specified by the coder.

This way, the compiler knows how code should behave and as a coder, your code becomes generally speaking more readable. This is one of the ways how we can use the compiler as our sight.

Which languages have a static type system?

We want to avoid dynamic type systems. Before you decide to learn a language, look at the type system. These languages have a static type system:

  • Java
  • Rust
  • C#
  • Swift
  • Kotlin
  • Haskell

Just ot name a few. Remember, the better errors a language has, the better the compiler can assist you.

Here is a list of languages that have a dynamic type system:

  • Python
  • Javascript
  • Php

Making scalable products is hard with these languages. Especially if you are coding with eyes closed.

Of course, type system is not everything. The C language has static types but is not memory save, so you may have to deal with a lot of memory bugs that are hard to fix. So consider your options before you learn a new language. Error messages are important.

I like Rust because it has a static type system, it is memory safe and it has amazing error messages that assist me well. Haskell has a strict and expressive type system and is memory safe. Typescript has good error messages too.

Java is also a good option. Static type system, memory safe and good error messages. I recommend java if you haven't learned a static typed language already. It has the stuff you want as a visually impaired coder and it reach the point that their is so much code out there written in java that you can easily find a job for it.

Next up, lets talk about indentation.

Why tests are so important for us

Unit tests are super handy for us. With a unit test, you can test a function and look if it behaves the way you want.

A good coder makes a mistake in 1 of 10 functions. A excellent coder makes a mistake in 1 of 30 functions. A visual impaired coder maybe makes a mistake in 1 of 3 functions.

But whatever your skill level may be, you make mistakes. Their are functions that do not behave as you wish they did. Good coders compensate their mistakes with unit tests. Because good coders do not make so many mistakes as we do, they do not depend on tests so much as we do so a lot of people skip them.

Here is where we as visual impaired coders can turn their disadvantage (introducing more bugs) in to a advantage. We need our tests in order to work. We introduce by accident possible bugs that we can later filter out with tests. This is why I write better code. I just write a test for every function and this way I get close to 100% test coverage.

Yes, we write code with more bugs, but we can compensate that with more tests and that way we build in the end more robust software then a visual coder who is too lazy to write tests.

Do not forget your tests. Almost every language has a system for writing unit tests, so learn how to use it.

Make build pipelines that last

Build pipelines are glorious when they work. The problem is that they sometimes break. This is annoying for people with sight but for people without sight this is even worse.

That is because many CI/CD products are not reproducible out of the box. When all your tools and dependencies are locked in a lock file, they will last because a update cannot change your program.

Also many CI/CD products work with YAML files. YAML is horrible. People try to use it as a sort of programming language while it is not. You can easily make syntax errors and if you want to debug your CI you need to push it to your repo and you'll have to find all the buttons on the webpage to see your error message.

Build pipelines should not be your focus when you are starting out but when you need to build a pipeline, use Nix or a better alternative.

Nix is a simple language. It is sort of like JSON with functions. With nix, You can easily define build pipelines that last.

  • You can make a build pipeline with nix for every language.
  • It is reproducible, meaning that all your tools are pined to a specific version. That way you can reproduce your build in the future.
  • You can test your build pipeline locally because your pipeline is reproducible. You can reproduce it on your local machine.
  • Because you can test your pipeline locally, you can read the error messages locally. No need to navigate a website with a screen reader.
  • Because it is reproducible, it will not break in the future. Once it works, it will always work.
  • Nix integrates with CI products such as github actions. Nix can build docker images. Learn once, deploy everywhere.

It is hard to hack a build pipeline together with a few yaml files here and their because we can only see one line at a time. We need structure, error messages. We should know what we are doing.

If you want to make a build pipeline, learn Nix. It can be a bit hard to learn but once you master it you can deploy software insanely fast. I recommend zero to nix. CI/CD is a hard. But when you have a visual impairment, working with YAML files and writing docker images is harder then writing a build pipeline in Nix.

Overcoming obstacles

This chapter is for overcoming mental obstacles practically.

"I am the true vine, and my Father is the gardener. He cuts off every branch in me that bears no fruit, while every branch that does bear fruit he prunes[a] so that it will be even more fruitful." - John 15:1-2

I am way to slow and this costs too much energie

I can code with eyes closed now and I am pretty fast. Still, I encounter this mental obstacle from time to time. Coding just takes more time and it costs more energie.

How I deal with being slow

Yes in many aspects a non-sighted coder is slower then I sighted coder. The key for me practically is The 20/80 principle.

Sighted people make so many mistakes when it comes to time management. Perfectionism is a hell for productivity. If you analyze in all your actions what the 20% was that ended up as 80% of the result, you can be way more productive.

If you can manage your time better, you can deliver more and better products. In the core, we are slower. But with enough optimizations we can be as productive.

Don't worry about being slow in the beginning. You have still much to learn and much to practice when you're starting out. In the beginning I was very slow too. I just wrote like 5 lines a day. Visualizing is hard in the beginning but you will get better and better.

About the energie part...

Take a break now and then. If you have partial sight, it is okay to take a power nap.

For me buying a new monitor helped a lot with energie. I bought a monitor with high contrast and I high DPI so that the text is sharp and easy to read.

The important thing is that you should not compare yourself too much with sighted people. Everything that visually impaired people do costs twice as much energie then for sighted people.

Do your best, but do not try to be the best. HAving a visual impairment is hard enough.

This is too hard.

I really doubted if coding with eyes closed was a thing that would work for me. Luckily I grinded until I could code with eyes closed and I am very happy that I can make whatever I want.

Coding is still a lot of fun with eyes closed. For me the fun part is coming up with solutions to problems. That is a game that you play in your mind. Not on a screen.

Coders with sight implement their ideas via a keyboard and light form their screen. Coders with little to no sight implement their ideas via a keyboard and sound from their headphones.

That is the only difference. So if you like to code because you like to think about problems and come up with elegant solutions, you will like to code with eyes closed.

If you want to code with eyes closed, I have a good mental advice if you consider quitting because it is too hard. Do not listen to sighted people who say that this is too hard for you.

It all comes from a good hart but sighted people are amazed if you cross the street with a cane. Even though when you did that 10 times it is not even hard.

If they think that is hard, how on earth can you take advice that coding with eyes closed is too hard for you? You should have higher expectations then those people.

Then again, these people are very kind. It all comes from a good heart but their thoughts are not so realistic when it comes to your capabilities.

Ready to code?

Exercises

We will start small. Practices makes perfect.

Now lets write code with eyes closed.

Ready to code?

This is the moment you've been waiting for. We are going to code.

Hello syntax!

goal: Get you familiar with syntax and screen readers.

Intro

Reading a program can be a bit hard. Sighted coders can see in a glance what is happening. Visually impaired coders can only see / hear 1 line at a time.

First, we need to get familiar with this new way of looking at a file.

The mission

  1. Download an editor that fits you. You can read the editors section for recommendations.

  2. Make an HTML file and paste some html in the file or write it yourself. Look around in the file with your screen reader. Do you know in which scope you are? When a html tag begins and when it ends?

Good luck!

Hello world!

Goal: Make a binary that prints hello world and get familiar with language servers and error messages

Intro

Being a coder is more then looking around in an HTML file. We want to use a programming language. You can read the programming language chapter about which language fits best.

We have an editor, we have a language that we want to use. Now let's bring those two together.

The mission

  1. Install the toolchain that you need for your language.
  2. Install a language server if it doesn't come with your editor already.
  3. Make an hello world project. Try to print hello world in the console or a hello world app.
  4. Change hello world into hello {your name}.
  5. Make a syntax error. Can you read the error? Can you use your language server to find the error?
  6. Expend your program so you have more then 1 function and more then 1 file. Can you navigate the files with shortcuts from your editor? Can you use a go to definition or Go to references to find the function you're looking for?

Good luck!

Advent of code

Goal: solve an advent of code puzzle.

Intro

Advent of code is an advent calender with coding challenges. It starts relatively simple. Of course, if you have little experience with coding with eyes closed. It is hard. That is why this a good training. This is a hard exercise. If you succeed, congratulations. You worked hard to get to this point and you can code with eyes close. Practice makes perfect. If this is too hard, try to do another exercises.

The mission

  1. Go to adventofcode.com and login. (You can login with github)

  2. Solve day 1 part 1.

  3. Solve day 1 part 2.

  4. Solve as many days as you wish.

  5. Try to push your solutions to a repository

Good luck!!

Terminal

Some simple exercises to get started with the terminal.

Navigating your files

Goal: Use a terminal with basic commands.

Intro

Terminal is hard. It is not for everyone. We learned that using a terminal is harder when you have a visual impairment. Still, their are some situations where you cannot avoid it.

This exercise is mainly for getting more familiar with the new nature of using a terminal.

The mission

You are only allow to use the terminal. No gui.

  1. Create a folder named folder-a

  2. Create a file in folder-a called file-a.txt that contains the sentence: I am a file. Nice to meat you!. Tip, you do not have to use an editor in the terminal such as vim or nano. You can use the echo command

  3. Copy file-a.txt and name it file-b.txt. Make sure that file-b.txt is in folder-a. Use the cp command.

  4. Copy folder-a with all the files and name it folder-b. Use the cp command.

Tip, you can read man-pages online with your screen reader instead of in the terminal.

Good luck.

git init

Goal: Use the git cli.

Intro

Sometimes, you want to use the git cli instead of a gui.

The mission

  1. Init a git repository.

  2. Make a commit with changes and a commit message.

  3. Push your changes to a remote using your terminal. If you do not have ssh configured, you should make a private and public ssh-key.

Good luck!

GitHub

Github is used a lot, so you better know how to use it.

Feel free to use gitlab or another hosting provider instead of github.

login

Goal: Get familiar with the login screen from github.

Intro

This one is easy. Login on github.com. If you do not have an account, you can make one on the website.

The mission

Login on github.com

star a specific repository

Goal: Get more familiar with searching for repositories.

Intro

Sometimes you want to search for a repository on github. Github's site has a lot of links headings and buttons. It can be hard to find the right button you're searching for.

The mission

  1. Search for a repository that you like. A tool, language, book or blog.

  2. Find the star button. Feel free to explore.

Good luck.

hearme.md

Goal: Read a readme with a screen reader.

Intro

Readme's are everywhere. Github makes readme's easy to read with screen readers. It turns markdown into accessible html pages.

The mission

  1. Find a repository that you like.

  2. Read a readme. Can you navigate quickly between sections? Installing, contributing.

Good luck.

Make an issue

Goal: Report a bug.

Intro

The open source community appreciate bug reports and feature requests. Try to make an issue. Feel free to open an issue for this book. You can probably find a spell mistake somewhere.

The mission

  1. Read the contribution guidelines for the project that you want to contribute for.

  2. Report a bug or feature request.

Make a pull request

Goal: Get familiar with reading code from someone else.

Intro

I really like open source software because I can make it accessible myself. If a button is labelled bad for instance, I can change the label so that it has a better description.

Reading someone elses code can be a challenge. Especially if that person is a bad coder. Opening a pull request is an good way to train with reading code that you did not write.

Feel free to open a pull request for this book if you find a spell mistake for instance.

The mission

  1. Find a project that you want to contribute to.

  2. Read the contribution guidelines

  3. Open a pull request.

Thank you!

Amazing that you've read the book. I really hope that I helped you in the right direction.

I want to thank people who helped me on this journey. Coding with eyes closed was a relatively long journey for me.

I want to thank God. It was such a hard time when I was diagnosed and he gave me everything I needed and more.

My eye disease brought me to Jesus who gave me strength to write this book and many other projects.

God gave me through his love so much. Such as:

  • bartimeus who learned me tips and tricks about screen readers, mobility and emotional support.
  • mike who gave me very helpful tips for coding with eyes closed. I do not know where I would've been without his tips, especially his braille advice.
  • eric who learned me braille with his amazing braille pi.
  • jurriaan for emotional and financial support and managing my cables when I could not see them :)
  • cor who motivated me and supported me on my nixos and rust journey.
  • My family for emotional support and motivation.

And he gave amazing contributors:

God bless all these people who helped me so much 🙏❤️👨‍🦯

Cheat sheet

This is a short summery with links that to the corresponding chapters that explain the idea in more detail.

This book is not a bible. It is meant to help you to guide you in the right direction.

Where to start

Start with MacOS or Windows. Once you are more comfortable with these platforms, experiment with linux if you need to. 3.1. Operating system

If you are on windows, learn NVDA. If you are on macos, learn VoiceOver. 3.2. Screen reader

You do not need braille to code. TTS is way faster and cheaper. 3.3. Should I learn braille?

Which tools are accessible?

Don't use a terminal if you depend on TTS. Terminals are great for people with partial sight. 4.1. Goodbye terminal life

If you are blind, experiment which editors works best for you. Do not use vim when you are starting out. Visual studio code worked well for me at the time of writing. (2023/01/15) If you have partial sight, use what you like most. Almost every editor has high contrast large text capabilities. 4.2. What's the most accessible editor?

Learn your stuff. If you want to learn a language, first read a book, then practice. This way you do not have to stack overflow everything together. Consider using AI Chat bots for searching for information. 4.3. Navigating websites

What language should I use?

This is the most important section of the book. I highly recommend reading the full chapter. 5. What language should I use?

You can see only a small portion of a script, so you should use the compiler as your sight. 5.1. The compiler is your sight

Dynamic types are blind. You are blind too. Dynamic types cannot lead you in the dark. Use static typed languages. Such as Java, Kotlin, Rust and many others. 5.2 Why dynamic types are even worse for some with a visual impairment

Use unit test as your sight. Write as many as possible. This makes debugging relatively easy. 5.3. Why tests are so important for us

Avoid yaml as much as possible. Use Nix to define your build pipeline and checks. 5.4. Make build pipelines that last

Overcoming obstacles

Speed will come. Don't compare yourself to sighted people. Compare yourself to yesterday. Learn how to use the 20/80 rule so you become insanely productive. 6.1. I am way too slow and this costs too much energy

Sighted people underestimate your skills. You can do way better then they think. Be kind to them, it all comes from a good heart. 6.2. This is too hard

Practice by trying a few exercises

About me

My name is Sem Pruijs, the author of this book. You can find me on: