Accessibility
Run the Command Deck with a screen reader. What --accessible changes, what stays the same, and how it's different from --plain.
stella's interactive surface is the Command Deck, a tabbed terminal interface. By default, it draws the way most full-window terminal apps do: it takes over the whole screen and repaints the grid many times a second. That works well for your eyes. It does not work for a screen reader, which gets a flood of changing text with no way to tell that a new line appeared. Worse, the whole conversation disappears the moment you quit, because the screen it drew on is torn down with the program.
--accessible changes how the deck talks to your terminal so a screen reader can follow
it.
This is a mode on the deck, not a separate, smaller tool. Every tab, every gate, every key, the prompt queue, sub-agents, steering, and resume work exactly the way they always do. Nothing is removed and nothing is simplified.
Turning it on
# One session
stella --accessible
# The same thing, spelled out
stella chat --accessible
# Resuming a session works the same way
stella resume --accessible--accessible is a global flag, and stella chat and stella resume are the two
commands that open the deck.
To make it your default, set the environment variable in your shell profile instead of typing the flag every time:
export STELLA_ACCESSIBLE=1The variable turns the mode on when it is set to anything other than 0. So
STELLA_ACCESSIBLE=1 and STELLA_ACCESSIBLE=yes both turn it on, while
STELLA_ACCESSIBLE=0 and an empty value leave it off.
--simple also works, and does the same thing as --accessible.
What changes
The deck stays on your screen
The session draws inline, right below your prompt, on your own screen. It never switches to a separate screen. Nothing above the deck gets hidden while it runs, and nothing gets destroyed when it exits.
Finished messages move into scrollback
Each finished message gets written into your terminal's normal scrollback exactly once. Your screen reader announces it as it arrives. You can scroll back through it with your review cursor. And it stays there after you quit. The live pane skips anything already written, so nothing gets read out twice.
Messages move into scrollback one agent lane at a time. The newest message in each lane stays in the live pane until the session ends, because it keeps updating while the response streams in.
Motion is frozen
Accessible mode turns on --no-anim automatically. The
progress bar's shimmer and pulse stop, and the caret stops blinking. No part of the
screen repaints on a timer, so there is nothing for a screen reader to mistake for new
content.
Panels stack into one column
The deck normally draws three areas as two panes side by side: the GRAPH tab, the
SKILLS tab, and the session's work rail. In accessible mode, these stack vertically
instead. No row mixes content from two panes, so the reading order goes top to bottom.
For the work rail, the deck uses the same layout it already uses on a narrow terminal: a
one-row status strip, with ⌃S opening the full view.
Grid views read as labeled records
A table only makes sense if you can see it. $0.05 sitting under a Cost header two
rows up works fine for your eyes, because you can see the column line up. Read aloud, it
is just the number five with nothing attached, because the spacing that carries the
meaning is whitespace, and a screen reader skips over whitespace.
So the TRACES, ISSUES, TOOLS, AGENTS, and INSTALLED tabs each show one record per row, with every value carrying its own label:
status running · cost $0.05 · cpu 3%Nothing is dropped. You get the same fields, in the same order, each one labeled. If a row is too long for your terminal, it gets cut off with an ellipsis instead of wrapping to a second line. That's because the deck scrolls one line at a time, and a row that wrapped to two lines would break the up and down arrow keys.
Moving somewhere is announced
Normally, changing tabs is obvious because the whole screen changes. In accessible mode, drawn inline, that same move is silent. The pane just repaints in place, with nothing to say you are somewhere new.
So each move writes a line into scrollback:
| You did | You hear |
|---|---|
| Switched tabs | ▸ SESSION tab |
| Opened an overlay | ▸ help opened |
| Closed an overlay | ▸ help closed |
| Focus moved to another agent | ▸ focus <agent-id> |
These overlays announce themselves when opened or closed: help, state, queue editor, sessions, context, inbox, inspect, transcript search, and the graph file picker. Things that open and close on almost every keystroke, like the slash menu and the composer's own popups, stay quiet on purpose. Announcing those would bury the moves that actually matter.
The program's own voice is marked
Messages that stella itself speaks, like "conversation cleared" and other system
notices, start with ▸. In the normal deck, you tell these apart by which column they
appear in. That works for your eyes but not for your ears. Without the ▸ marker, a
screen reader would make it sound like the model itself said "conversation cleared."
The cursor and the mouse
The text cursor sits at the real insertion point in the composer. That is what a screen reader follows, and what a Chinese, Japanese, or Korean input method uses to place its candidate window.
Mouse capture is always off in accessible mode, even if something else asks for it. A captured mouse takes away your terminal's own text selection, and several assistive technologies rely on that selection to read the terminal.
What stays the same
Everything else. All nine tabs, the prompt queue, sub-agents, steering a running turn, permission gates, slash commands, and resume all work the same way, with the same keys and the same behavior. If a feature works in the deck, it works here too.
Terminal limits
Drawing inline means stella needs to know where your cursor is right now. It asks your terminal for this, then waits for an answer. Every real terminal emulator answers. Some minimal terminals and most automated test tools do not, and the request times out.
When that happens, the deck still starts. It still draws on your own screen, never a separate one, but it turns off the scrollback flush and tells you:
accessible mode: this terminal did not report its cursor position, so messages stay in
the deck pane instead of moving into scrollbackThis message shows up on purpose instead of failing silently. The whole point of accessible mode is that finished messages become permanent output. Quietly failing to deliver that would be worse than not offering it at all. If you see this notice, everything else about the mode still works: stacked panels, labeled records, frozen motion, and marked notices. But the transcript stays in the live pane, and announcements have nowhere to go.
--accessible or --plain?
They answer different questions.
--accessible | --plain | |
|---|---|---|
| The question it answers | There is a terminal, but the thing reading it is not a pair of eyes | There is no usable terminal here |
| What you get | The full Command Deck, drawn inline | A line-based REPL |
| Features | All of them | A smaller command set; no tabs |
| Needs a TTY | Yes, on both stdin and stdout | No |
| Env | STELLA_ACCESSIBLE=1 | STELLA_PLAIN=1 |
Use --accessible when you are at a terminal with a screen reader. Use --plain for
pipes, CI logs, TERM=dumb, and anywhere there is no interactive terminal at all. The
deck switches to the REPL automatically in those cases anyway.
Accessible mode has no say in that choice. If stdin or stdout is not a terminal, you get the REPL whether or not you asked for accessible mode. An inline viewport needs a real terminal just as much as a full-screen one does.
Related terminal controls
These are independent of --accessible and work on their own:
| Control | Effect |
|---|---|
--no-anim / STELLA_NO_ANIM=1 | Freezes deck animation to a static frame. Implied by --accessible. |
NO_COLOR | Turns colour off, and also freezes deck animation. |
TERM=dumb | Switches ANSI output off entirely. CLICOLOR_FORCE overrides it. |
--plain / STELLA_PLAIN=1 | The line REPL instead of the deck. |
Check it works
Start a session with stella --accessible and look for these, in order:
- Your prompt is still visible above the deck. If the screen cleared and your
scrollback disappeared, the mode is not on and you are on the full-screen view. Check
for a
STELLA_ACCESSIBLE=0in your environment that might be overriding your profile. - No fallback notice. If you see the cursor-position message shown above, your terminal did not answer, and finished messages will stay in the pane instead of moving to scrollback.
- Ask something, and let the turn finish. The finished message should be in ordinary scrollback. Scroll your terminal up, or use your screen reader's review cursor, and you should be able to reach it as normal text.
- Press
⇥. You should hear▸ AGENTS tabor similar. - Quit. The conversation should still be on screen.
Reporting a gap
Accessibility here just means ordinary, sequential terminal output, which every screen reader already handles. There is no special terminal accessibility API to target, so there is nothing reader-specific to configure. If some part of the deck still does not read correctly, file a bug on the issue tracker and name your terminal emulator and screen reader.
See also
stella chat— the command reference, including every flag- Agent Modes — the other ways to drive stella
Agent Modes
The different ways to drive stella — chat in the Command Deck, one-shot runs, judged goal mode, CI monitoring, and parallel fleets — and how to pick between them.
Self-improvement
How stella learns from its own work. The parts that change what it can do, what each one checks before a change sticks, and how to undo each change.