The content-specific user interaction described above is a very powerful feature of Emacs, and this is where Emacspeak derives its power. Traditionally, the ability to create buffers specialized for working with specific content-types has been used by the Emacs community to develop versatile programming environments, messaging applications such as mail and news readers, and authoring environments. The clean design present in all of these Emacs extensions in terms of separating application functionality from the user-interface, combined with the availability of the entire source code making up these packages under the open-source model has laid the ground-work for developing Emacspeak as a versatile aural counterpart to the product of years of software engineering that has been invested by the Emacs community. In short, Emacspeak would not exist in its present shape or form without this prior effort.
Emacspeak takes advantage of the content-specific knowledge available within specialized buffers to produce “audio formatted” output designed to optimize user interaction. A basic consequence of the above is “voice locking” in specialized modes; a more interesting consequence is the implementation of Aural Cascading Style Sheets (ACSS) in conjunction with the Emacs EWW (Emacs Web Wowser) and W3 Web browsers.
Emacs derives one final advantage from using buffers as the basic building block for the entire desktop. Every Emacs buffer is searchable via a uniform and powerful search interface. Emacs’ incremental search works efficiently and consistently to enable you locate “objects” of interest either within a given document or to locate a given object from among the various objects that are currently open on the Emacspeak desktop. This is very powerful — where a GUI (Graphical User Interface) user is typically limited to quickly locating an object from a relatively small collection — the size of the collection being a direct function of available display real-estate — the Emacspeak user can typically work with a far larger collection of objects. This is well-suited to the eyes-free environment, where display real-estate has no meaning; so bringing up a list of currently open buffers and performing an incremental search to locate a specific buffer is just as efficient independent of whether you have a few dozen or a few hundred buffers open.
To illustrate the above, my typical working Emacs session lasts between two and three weeks — over that time I typically accumulate several hundred open buffers holding a large variety of content ranging from program source code to email messages and WWW pages.
Ubiquitous search in the eyes-free environment is critical — as a comparison, when using a conventional, purely visual WWW browser, users have no means of easily “searching” for say the “submit” button on a WWW page. This inability is a minor annoyance in visual interaction, and the typical mouse-enabled user never uses the find dialog to find a submit button — it is simply more efficient to point at the submit button given the eye’s ability to quickly scan the two-dimensional display. This luxury is absent in an eyes-free environment; as a consequence, blind users confronted by the combination of a visual interface and screen-reader are typically limited to either tabbing through all the controls on a WWW page, or using the sub-optimal find dialog.