Is a terminal a user interface?
We argued for twenty years that screens should be readable, then moved our working day into one nobody ever measured.
We have spent twenty years making one argument: a screen someone has to read must be readable by the people who have to read it. We made it about web pages, then about apps, then about documents and email and dashboards.
Somewhere in the middle of that, an enormous amount of professional work moved into a black rectangle full of low-contrast gray text. Almost nobody carried the argument across.
A terminal is a user interface. It has readers with low vision. This is barely being said anywhere.
Who gets excluded by a default theme?
Start with the specific person, because "accessibility issue" is a phrase that lets everyone stay comfortable.
A developer with low vision. A designer with astigmatism reading dim text at the end of a long day. Anyone whose contrast sensitivity is ordinary rather than excellent. They are looking at a palette where "helpfully de-emphasized" output sits at 2.1:1 against its background. WCAG 1.4.3 asks for 4.5:1 on body text, and this is software that runs for eight hours a day.
Now notice the second-order effect, which is the one that bothers me most. If the tools of a trade are only comfortable for people with a particular kind of eyesight, then the set of people who can work in that trade narrows. Quietly. Without anyone deciding it. One default theme at a time.
The accessibility of what we build everything else with is not a niche concern. It decides who gets to do the building.
Is anyone actually at fault here?
No, and I want to say that plainly.
Coding agent tooling is roughly eighteen months old as a category. Its conventions are still soft: keyboard behavior, focus, contrast, how a long-running job announces it has finished. All of it is being decided now, mostly by people solving a hard problem who have never been asked to think about exclusion. These are projects that would take a patch from anyone who turned up with one.
That last part deserves more attention than it gets. The door is open. Very few people are walking through it.
Atomic (opens in a new tab) is an open-source coding agent runtime by Bastani.ai that turns an engineering process into explicit, checkable execution graphs. I contribute accessibility to it, starting with the interactive theme, and the sequence turned out to matter more than the code.
How do you add a gate to a project you do not own?
Three passes, and the middle one is the lesson.
First, a contrast helper with a report-only baseline. Report-only on purpose. Turning a new gate on hard, in someone else's project, breaks their build on day one and teaches everyone to resent the gate, and the gate is the thing we are trying to keep. Measure first. Publish the number. Let it be uncomfortable. Then tighten.
I have watched well-intentioned accessibility work fail this way more than once. Not because it was wrong, but because it arrived as an obstacle before it arrived as information.
Then the correction. The first version measured colors against an artificial canvas: foreground hex, background hex, compute the ratio. That is not what a terminal does. A terminal theme is not a set of colors in a file; it is what the terminal actually paints once a palette, a transparency setting, a dimming rule and a background have all layered on top of each other.
The number in the config and the light that reaches someone's eye are two different numbers, and the gap between them is exactly where contrast failures live. The tool had been looking at the wrong side of it.
Then a baseline saved into the repository. The measurement gets checked into the repository, so it is a fact a change has to argue with, rather than a number somebody ran once, on their machine, in a week nobody remembers.
What else in our stack has readers?
Terminals are the clearest case, not the only one. Once you start looking, the list of interfaces we exempt from our own standards is uncomfortable.
CI output, which people read under pressure when something has broken. Log viewers. Internal dashboards built in an afternoon. Error states in our own design tooling. Documentation sites with gray-on-gray code samples. The admin interfaces nobody demos. Every one of these has readers, and almost none of them have ever been measured.
They share a property: they are built by us, for us, which is exactly the assumption that hides exclusion. For us silently means for people who work the way I do.
What does this look like in your own toolchain?
- Measure before you gate. Publish the number first. A baseline is information; a failing build is an obstacle, and information persuades where obstacles harden.
- Measure what renders, not what is declared. Composited opacity, theme layers, dim attributes: the file and the pixel disagree, and the pixel is what a person receives.
- Commit the number. A measurement in the repository survives the person who ran it. A measurement in a screenshot does not.
- Include internal tools in the standard. If it has a reader, it has a contrast requirement, whatever the audit scope says.
- Turn up with the patch. Conventions in young categories are changed by whoever arrives with a working diff.
People do not ship inaccessible terminals because they do not care. They ship them because nothing in the toolchain ever mentioned that the contrast was 2.1:1.
The conventions of this category are still being written, and a patch still changes them. Pick one tool your team stares at all day and measure what it actually paints. Then turn up with the number.