A braille display shows very few characters at once
Aliases: braille display · braille cells · paperless braille
What it is
A typical refreshable braille display is a single row of a dozen to forty cells; forty is already wide. The finger does not get a page. It gets a short sliding window. A button name on screen can take most of that row.
Why it happens
Each cell is a set of piezo pins forming one braille character. Cost, power, and width pin the cell count to a small constant. The user pans the window across the content with keys, exposing only the characters inside it. The spatial shape of a paragraph, how many blocks a screen has, do not exist in that row. What exists is “these few characters in the current window” and “whether there is more to the right.”
Because the window is narrow, every string sent to the display is billed per cell. Role and state, if also rendered as braille words, compete with the name for the same row. Speech can be sped up; cell count does not grow with expertise. Expertise is panning the window faster, not a wider window.
Studying it
Attach a display (or the reader’s braille preview) and complete “find the button and confirm its state.” Count pans per task and what fraction of the name fits in one window.
Independent variables: cell count (14 / 20 / 40), name length, whether role and state are output too. Dependent variables: pan count, fraction of names truncated, time to locate the target.
Compare the same task in speech only: speech may finish in one utterance while the display is still panning. “Can read braille” is not a substitute for “can read a UI in this narrow window.”
Where it stops holding
Multi-line or notetaker-width devices ease the squeeze and still fall far short of a screenful of print. Reader users who never use a display are not bound by cell count. Specialized codes for maths or music occupy more cells, so the same content gets tighter. Treating desktop braille output as if it were a full page of paper braille underestimates how narrow the window is.
Applying it
- Write short names for AT as if they must fit a braille window: the name itself should be feelable in one row, not require three pans to learn which button this is.
- Do not make primary-flow controls identifiable only by a long sentence.
- How to check: set the display width to twenty cells and feel through the primary task. Objects whose names do not fit and need a chain of pans are already limited by cell count.