One of the questions raised was how do audio interfaces differ from visual interfaces. I believe this passage explains it very well:
Audio interfaces present content linearly to users, one item at a
time. This contrasts with the way in which most people use visual
interfaces. Sighted users can scan an entire screen almost
instantaneously, comprehending the overall layout, the artistic style,
and other macro-level aspects of the content. Screen reader users
cannot comprehend these macro-level aspects as quickly. The linear
progression through the content from beginning to end is somewhat like
automated telephone menu systems which do not reveal all of the
options at once. Users must progress through such systems in a
Reading speed: Most people relying on audio cues rely on screen readers to get acess to content.The content read using screen readers can be read at speeds ranging as much as 300 words/minute or more. The reading speed is never fixed and can be varied and it depends on the experience of the reader as highlighted below:
Screen readers do not read web content quite like human beings do. The
voice sounds somewhat robotic and monotone. In addition, experienced
users often like to speed up the reading rate to 300 words per minute
or more, which is more than the inexperienced listener can easily
understand. In fact, when many people hear a screen reader for the
first time, at the normal rate of about 180 words per minute, they
complain that it reads too quickly. It takes time to get used to a
screen reader, but the interesting thing is that once users get used
to it, they can race through content at speeds that can amaze sighted
With regards to setting to the standard reading speed for users, there is this interesting discussion on this site about the question of A question on Screen Reader Speed Standards .
This discussion mainly talks about how many screen reading software’s allow users to set reading speeds on a scale to acclimatize themselves and what are the challenges involved in determining those scales
How do screen readers read content and how that should influence are design/content decisions - Since most of the content which is read using screen readers is on the web,most of the guidelines are applicable to them but I guess they could be extended to software based interfaces too. Here are some of the guidelines with regards to how content is read and rendered into audio cues
- Screen readers pause for periods, semi-colons, commas, question marks, and explanation points.
- Screen readers generally pause at the end of paragraphs.
- Screen readers try to pronounce acronyms and nonsensical words if they have sufficient vowels/consonants to be pronounceable; otherwise,
they spell out the letters. For example,NASA is pronounced as a word,
whereas NSF is pronounced as "N. S. F." The acronym URL is pronounced
"earl," even though most humans say "U. R. L." The acronym SQL is not
pronounced "sequel" by screen readers even though some humans
pronounce it that way; screen readers say "S. Q. L."
- Screen reader users can pause if they didn't understand a word, and go back to listen to it; they can even have the screen reader read
words letter by letter. When reading words letter by letter, JAWS
distinguishes between upper case and lower case letters by
shouting/emphasizing the upper case letters.
- Screen readers read letters out loud as you type them, but say "star" or "asterisk" for password fields.
- Screen readers announce the page title (the attribute in the HTML markup).
- Screen readers will read the alt text of images, if alt text is present. JAWS precedes thealt text with the word "graphic." If the
image is a link, JAWS precedes the alt text with "graphic link."
Please read the remaining guidelines here
This is a good read: Usability Tips and Tools for the Visually Impaired on the Web
With regards to the challenges of designing accessible solutions with audio specific output for devices such as smart phones and devices which no longer provide a perception of haptic touch,I would strongly recommend reading this excellent CHI paper Usable Gestures for Blind People: Understanding Preference and Performance by my professor and one of my TA's :). To quote what the paper says about the challenges involved in designing for accessibility in smart phones
Though screen readers are now included in android and apple phones,
accessible touch screens still present challenges to both users and
Users must be able to learn new touch screen applications quickly
and effectively, while designers must be able to implement
accessible touch screen interaction techniques for a diverse range of
devices and applications. Because most user interface designers are
sighted, they may have a limited understanding of how blind
people experience technology. A designer who wishes to create a new
accessible touch screen-based application currently faces several
- First, while touch screen interfaces for sighted users are largely consistent due to now-familiar gestures such as
tapping, swiping, and pinching, touch screen interfaces for blind
users vary widely across platforms.
- There exist very few examples of how to extend accessible touch screen interfaces to devices other than smartphones.
- a designer who wishes to provide gestures in their application must consider whether the gestures will be
appropriate for a blind user. Although blind people may use the same
hardware as their sighted peers, it is possible that they will
prefer to use different gestures, or that they will perform
the same gestures differently than a sighted person. Sighted people
perform gestures differently when they lack visual feedback , and it
is reasonable to assume that a blind person may also perform
gestures differently than a sighted person.
To summarize his findings with regards to designing smartphone interfaces for blind users(note all the findings are not applicable from a audio cue point of view but do highlight factors which would help in better audio generation for ease of use)
- Avoid symbols used in print writing. Blind users may have limited knowledge of symbols used in print writing, such as letters, numbers,
or punctuation. Even when these symbols are known, users may not
be used to them or may not be comfortable performing them.
- Favor edges, corners, and other landmarks. Locating precise spots on the touch screen surface can be very
difficult for a user who cannot see the screen. The physical edges
and corners of a touch screen are useful landmarks for a blind
person. Placing critical functions in these areas will improve
accessibility and reduce the likelihood that the user will trigger
these functions accidentally. Reduce demand for location accuracy.
Blind users may be less precise in targeting specific areas of
the screen, including edges and corners. This problem can be reduced
by increasing target size or by allowing approximate
targeting methods, such as allowing a user to touch near a target and
then explore with their finger to locate it more precisely.
- Limit time-based gesture processing. Blind people may perform gestures at a different pace than sighted people. Thus, using
the gesture’s speed as a recognition feature or as a parameter (as
in kinetic scrolling) may result in increased errors for blind
- Reproduce traditional spatial layouts when possible. Objects with familiar spatial and tactile layouts, such as a
QWERTY keyboard or telephone keypad, are instantly familiar to
many blind people. Reproducing these layouts may make it easier
for a blind person to learn and use a new interface.
Lastly,the project slide rule video shows how audio cues can help a blind person use a smart phone
Whew thats a long post :)