You’ve probably never thought about how your CLI tool’s fancy spinner affects a visually impaired developer. But someone at Google, Anthropic, and GitHub did—and they all had to build the same fix from scratch. Not once, but three times. For the same problem. In the same year.
Let that sink in.
We’re obsessed with web accessibility. We audit our websites, add alt text, and celebrate WCAG compliance. Meanwhile, the terminal—the primary workspace for millions of developers—is a silent, unregulated accessibility desert. And the worst part? We’re making it worse.
Accessibility isn’t just for websites. It’s for the place where developers actually live.
Every time you add a spinning animation, a progress bar, or a boxed table to a CLI tool, you’re potentially shutting out a whole group of users who rely on screen readers. These tools don’t just fail to announce the spinner—they produce garbled, confusing output because the screen reader tries to interpret animated characters as text.
So what did the big guys do? Anthropic, Google, and GitHub each independently built a hidden feature: if a screen reader is detected, their CLIs switch from animated spinners to plain text. A simple, elegant fix. But they each built it alone. No shared library. No open-source standard. Just three separate engineering teams burning the same hours on the same problem.
That’s where term-a11y comes in. It’s a lightweight, reusable library that auto-detects screen readers and replaces animated spinners with plain text output. One library. One fix. No more reinventing the wheel.
The fact that this fix had to be reinvented three times is a damning indictment of our industry’s priorities.
We spend billions on AI assistants and pixel-perfect UIs, but we can’t spare a few developer-hours to make the terminal accessible. The irony is brutal: we’re building tools that help us write code faster, but we’re leaving behind the very people who could benefit most from those tools.
I’m not saying every CLI tool needs to be accessible today. But if you’re building a tool that uses animated spinners, you have a choice. You can keep ignoring the problem, or you can drop in a library that takes five minutes to integrate and changes someone’s entire workflow.
I saw this firsthand. A visually impaired developer told me they had to avoid using certain CLI tools because the output was unreadable. They had to ask colleagues to run commands for them. That’s not a technical limitation—that’s a design failure. And it’s a failure we built into our tools without thinking.
We thought we were making terminals beautiful. We were actually making them worse for a whole class of users.
So here’s the challenge: next time you add a spinner to a CLI, ask yourself—does this help the user, or does it just look cool? And if you’re serious about accessibility, stop reinventing the fix. Use term-a11y. Or build your own—but for the love of open source, share it.
Because the terminal is where we live. And it’s time we made it a place for everyone.
FAQ
Q: Why should I care about CLI accessibility if most developers are sighted?
A: Because the developer community is not a monolith. Visually impaired developers exist, and they deserve the same productivity tools. Also, thinking about edge cases often leads to better design for everyone.
Q: Isn't this just a niche problem that a few companies already solved?
A: Exactly. The fact that they solved it three times independently proves it's not niche—it's a recurring problem that no one standardized. A reusable library saves everyone time and ensures consistency.
Q: Won't this make CLI tools ugly?
A: Only if you think plain text is ugly. Accessibility doesn't mean removing beauty—it means providing an equivalent experience. Users can still have animations; screen reader users get readable output. That's not a trade-off; it's a choice.