Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Screen readers attempts to identify and interpret HTML and send its data to a standard output which may be a video monitor, a text-to-speech output device or a braille output device. It is a way to make the web and other screen activities available for challenged users.

A Voice browser can't interpret HTML and is bound to VoiceXML and other non-HTML protocols, making implementation on the web more costly, since developers need to present content redundant in HTML and another markup language (VoiceXML).

To me it looks like money spent on making your HTML markup available for screen readers a better investment than trying to implement support for voice browsers. Are support for voice browsers really necessary when screen readers are available?

share|improve this question
    
that's not what a screen reader does, it doesn't interpret HTML. –  Andy Dec 30 '12 at 20:46
    
That's right, they interpret what's on the screen. I'm editing now. Thanx for the heads up! –  Benny MCSA Office365 Dec 30 '12 at 20:50
    
A voice browser, from my understanding, is basically a web based IVR. One could argue it's redundant, but I imagine tailoring the system specifically for IVR-type interactions can be useful. –  DA01 Dec 30 '12 at 22:46
2  
Screen readers technically read 'the screen' but many newer ones can also interpret the HTML (and possible aural CSS, though not sure support levels for that yet) –  DA01 Dec 30 '12 at 22:47
    
@DA01 That's what I thought, but am currently on thin ice, since I know very little from these techniques. That's why I'm asking :-) Rolling back edit. –  Benny MCSA Office365 Dec 30 '12 at 23:09

2 Answers 2

up vote 1 down vote accepted

Voice Browsers and Screen Readers are really two separate technologies that just both happen to use TTS, but that's about as much as they have in common.They're really separate technologies with separate audiences, goals and concerns. Here are some of the main differences that come to mind:

(Disclaimer - my background is very much on the screenreader/accessibility technical side of things, so I might be making some incorrect assumptions about real world Voice Browser usage here!)

A Voice Browser assumes both voice input and output. By contrast, screenreader users typically use keyboard for input, and may use voice, or braille, or even both simultaneously for output. Some screenreader users may use braille exclusively, so don't assume that screenreader involves speech at all!

A Voice Browser is a full user-agent in its own right. By contrast, a screenreader is really providing an alternate view of the UI provided by the browser, which is acting as the 'real' user-agent. A screenreader user is fundamentally still interacting primarily with the underlying browser (whether IE, Netscape, Safari etc) and all its UI (bookmarks, tabs, preferences, etc), although they perceive r via the screenreader.

Voice browser content is often authored specifically for a voice context, so that any user who connects to the system can explore and navigate the content and complete specific relatively simple tasks without prior training. By contrast, screenreader users are accessing exactly the same content as any other browser user. There is a steep learning curve to using a screenreader, and this involves learning the many mechanisms that a screenreader offers for navigating through complex structured web pages. For example, a screenreader user may use one hotkey to jump between different heading levels in the document, or another to find a link with specific text content, or another set of hotkeys to navigate between rows and columns of a table - with other hotkeys available to cancel, pause or restart speech output (...if they are even using speech at all).

Voice browser output voice is typically at normal human speech rates, and often uses "natural sounding" speed, pitch and inflections. By contrast, most screenreader users will increase the output speed so fast that a non-screenreader user will just hear a stream of gibberish and perhaps catch only one or two words as it speaks. For a screenreader user, "natural sounding" is a secondary concern, and they will typically customize the speech output parameters to something that they personally find comfortable to work with at high speeds over long periods. (Aural CSS will likely not be relevant for screenreaders scenarios for this and other reasons; in a screenreader context, the output voice belongs to the screenreader user, not the content author.)

So the real question is whether any given application requires voice browser support in the first place - and that has to be addressed on its own terms. The presence of screenreaders and support for them doesn't influence that evaluation either way.

share|improve this answer
    
+1 for a superb answer! Thanx –  Benny MCSA Office365 Jan 7 '13 at 19:49

Voice browser is a custom solution for people who can't see, while screen reader is a way to target people who can't see for services that are primarily designed for mainstream audience.

To answer your question, yes it's necessary to have a tool like that for developers to use. Since what if I am trying to make a website that is for people who can't see, exclusively? That's a situation where voice browser is more appropriate than a screen reader. Since for a website like that you don't even need anything visual as there are no audience that can see, a screen reader is not even usable in this situation as there is no screen to be read.

share|improve this answer
    
A voice browser isn't necessarily for people that can't see. It certainly can be used for that, but it's also a way to use it as an IVR...which is useful for most any type of person at various times. –  DA01 Dec 30 '12 at 22:48

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.