Designing a Terminal for an Audio-First Workflow | The Accessible Engineer: Derek Riemer

Skip to main content

Designing a Terminal for an Audio-First Workflow

Most shell environments assume a visual interface. Prompts are colorful, information-dense, and optimized for quick scanning. My workflow is different. I'm blind, and I work with a screen reader, which means my terminal is fundamentally an audio interface. Instead of scanning the screen, I'm listening to the environment as I work. That changes what matters.

Most terminal workflows carry a lot of unnecessary noise such as long paths, redundant context, and visual-only cues. Designing for audio forced me to remove that noise entirely.

The result is a shell environment that’s faster to navigate, easier to parse, and often better even if you can see the screen. If you like what I describe here, take a look at my dotfiles repo for your own inspiration. If you are interested in what path substitution built directly into shell configuration might look like, and maintain shell code, I'd love to talk.

Where this started

While I was working at Google, I spent a lot of time inside the monorepo. (If you haven't encountered that model before: imagine nearly the entire company's code living inside one enormous repository). The ideas that eventually led to this system started there, but the implementation in this repository was written later from scratch and is entirely my own code.

The paths were extremely long. In some cases it could take several seconds for my screen reader, even reading at 700 WPM, just to tell me where I was during a large refactor. A typical path might look something like this (simplified):

/mounted/path/to/the/monorepo/perforce_client/root/javascript/namespace_part/namespace_subpart/namespace_subpartsubpart/app_root/subsystem/main/tests/audioInformation_test.ts

For a sighted developer, this is mostly a visual annoyance. You glance at the prompt, pick out the important segment, and move on. For me, the terminal had to speak the entire thing, or I had to interrupt my work and read it piece by piece. Every time the prompt appeared, my screen reader would start reading the path, and after a while I realized I often had no idea where I was unless I waited several seconds for the prompt to finish speaking. That was not going to work.

So I started building tools to compensate. First came "teleport" functions. These were small helpers that jumped directly to important parts of the repository:

function jsdf {<br>cd

function jdf {<br>cd

I can't show the real internal layout because I don't want to reveal how Google's internal monorepo is organized, but jsdf simply meant "JavaScript Drive frontend code." This saved a ton of time in typing along, a simple jsdf;cd infra would get me somewhere I needed to be to do something on a specific file, but it wasn't enough. These worked, but they were crude, and I was still constantly hearing huge paths in the prompt. Eventually I added a small rewriting pipeline that shortened common segments before displaying the path. The first version was extremely simple:

sed -e 's/path_1/short_segment/' \<br>-e 's/path_2/another_short/'

It was ugly, but it proved something important: shortening paths dramatically reduced cognitive load. To make that concrete, here is the kind of transformation I was trying to achieve.

Before:

/mnt/c/users/driem/programs/python/ai_image_describer/main/tests/audioInformation_test.ts

After:

py/ai_image_describer/main/tests/audioInformation_test.ts

Saving keystrokes was important, but not as important as saving attention. Hearing a short, predictable path segment is far easier than listening through a long directory hierarchy every time the prompt appears. At Google, the savings was well over two thirds the path length, and left me more mental capacity to actually think about the problem at hand. That idea eventually evolved into the alias and namespace system I use today.

Making terminal sessions resilient

My workflow makes this problem harder to ignore. At Google, and still today, I am often working from home, a café, my desk, or even while camping in the middle of the desert, so most of my development happens inside a persistent tmux session on a remote machine. I jump between windows, reconnect from different devices, and keep long-running work alive in the background. That means I'm constantly re-orienting myself: switching panes, reattaching sessions, and resuming work. Every time I do, the first thing my terminal speaks is the full working directory. If that path is long, I'm back to waiting several seconds just to answer a simple question: "Where am I?"

Path aliases

The first step was simple: shorten frequently used paths. For example, instead of typing cd /mnt/c/users/driem, I can define an alias:

driem /mnt/c/users/driem

and then navigate with:

p driem

The p command is a thin wrapper around cd, backed by the alias map. I also use pd for pushd when I want a quick...