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=1

The 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 didYou 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 scrollback

This 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 answersThere is a terminal, but the thing reading it is not a pair of eyesThere is no usable terminal here
What you getThe full Command Deck, drawn inlineA line-based REPL
FeaturesAll of themA smaller command set; no tabs
Needs a TTYYes, on both stdin and stdoutNo
EnvSTELLA_ACCESSIBLE=1STELLA_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.

These are independent of --accessible and work on their own:

ControlEffect
--no-anim / STELLA_NO_ANIM=1Freezes deck animation to a static frame. Implied by --accessible.
NO_COLORTurns colour off, and also freezes deck animation.
TERM=dumbSwitches ANSI output off entirely. CLICOLOR_FORCE overrides it.
--plain / STELLA_PLAIN=1The line REPL instead of the deck.

Check it works

Start a session with stella --accessible and look for these, in order:

  1. 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=0 in your environment that might be overriding your profile.
  2. 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.
  3. 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.
  4. Press . You should hear ▸ AGENTS tab or similar.
  5. 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