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.
