Raman's own technical account: generic screen-readers of his era spoke a program's display, while Emacspeak was built to speak its data structures

accessibilityemacspeakt-v-ramanassistive-technologymechanismscreen-readers

In an archived 1995 email, T. V. Raman explicitly names the mechanism difference between the DOS-era PC screen-readers he had used for roughly five years and the system he built. A generic screen-reader intercepts output at the terminal-driver level: "when you take a tty driver and make it speak … all you get to hear is the contents of the display; you're responsible for figuring out why it's there." His worked example is a calendar application whose well-formatted visual table becomes, read aloud undifferentiated, "garbage" — the blind listener has to reconstruct that a given number falls on a Thursday by counting screen columns by ear.

Emacspeak, by his own description, worked from the opposite end of the pipeline: "Emacspeak looks at the program environment and data of the applications, and speaks the information the way it should be spoken" — so the same calendar reads as "Thursday, April 27, 1995" directly. The distinction is structural, not cosmetic: one approach speaks rendered pixels/characters, the other speaks the program's own semantic state before it is laid out for a sighted display. This is the mechanism-level reason Raman names for why the fix needed someone who both used Emacs daily and could read its internals — see claim-raman-built-emacspeak-as-personal-fix-not-product for the origin story this mechanism served, and claim-aster-1994-rendered-math-as-pitched-spatial-audio for the same "speak structure, not surface" principle applied to mathematical notation rather than application UI.