First Thoughts: Term-accessibility

I’ve seen a fair amount of chatter recently regarding accessibility of terminal apps, and it has me thinking. There’s been a recent growth of both full TUI toolkits and of lighter cli polish and shine modules, lots of tools to make the terminal more accessible and generally more comfortable for the average user, but it can come at a cost – these kits can make the cli less accessible to some sets of users, especially people with low vision, using screen readers or other assistive technology.

The growth of terminal tools is, in general, a good thing! The cli is a powerful environment, and more people should be comfortable working there. It’s crucial, though, that in making it easier for some, we don’t put up new barriers for others.

This brings me to my point: we need a way to transparently signal accessibility needs to cli tools and toolkits. I propose a common flag for terminal accessibility needs, which can be set and read from a standard location in a lightweight manner.

My initial thought is a dot file and an env var, `~/.term-accessibility` and `TERM_ACCESSIBILITY`. At a minimum, cli apps can check for the presence of this file/var and default to a plain text UI rather than the fancy TUI. We can offer more granularity by defining well-known values, eg. to disable ANSI colours or box-drawing characters, to restrict redraws or cursor control, etc.

There’s a few ways to handle the flags on the developer side. The absolute easiest would be for library developers to adopt this; for example, `chalk` could automatically replace its exports with NOPs if the flag is set. Next best would be a shim module, something like `chalk = require(‘chalk-term-accessibility’)`, that replaces the exports as needed. There may be ways for kits like `blessed` and `ink` (a React-in-the-terminal project) to adjust their behaviour automatically if they know they are working with a screen reader, or the app can default to a text UI.

As far as content for the flags, I have a few ideas: nocolor, nographic, noanimation, to disable specific terminal features; screenreader and linemode, maybe charstream and wordstream to indicate specific modes of interaction. There is some overlap with existing terminal flags, which we could leverage in the module to set defaults in the absence of an explicit term-accessibility flag.

I think I will start doing this immediately in my personal projects, and will bring it up at work for our cli tools. It’s a small step to take, and can make and keep the terminal a better place for everyone.

I welcome comments, feedback, even pointers to existing projects that I’ve missed.

Author: Eddie Roosenmaallen

By day I'm the Release Manager at Distributive; I help build the Distributed Compute Protocol at In my off time I explore Linux, JavaScript and the web, and I try to share some of my knowledge and some of my humour online.