On Thu, Jul 7, 2011 at 10:31 AM, Peter Korn <peter.k...@oracle.com> wrote:
> ** > Sylvia, all, > > My point with cloud-based TTS is... there are a number of TTS engines out > there. Some open source, some > commercial-but-free/cheap-to-use-over-the-web. Wouldn't it make for a much > tighter integration & more powerful UI to have a media player that generates > the TTS and automatically does the pausing/unpausing? > The media player is the Web browser. Do you mean that the Web browser should generate the TTS or that a could service does the TTS? It seems you are saying both, which doesn't make much sense to me. Can you clarify how you see this working? Seems less complex than relying on screen reader vendors to support a new > API that must first also be supported by the (HTML5 capable) browsers. > The specification in HTML5 already exists: http://www.w3.org/TR/html5/video.html#attr-track-kind-keyword-descriptionsand is starting to be implemented in browsers ( http://blog.gingertech.net/2011/06/27/recent-developments-around-webvtt/). Also, I think using screen readers is a lot less complex than using a cloud service for TTS, which has to hook into the browser's video element. But I may be missing something - can you explain how that would work? The text file that contains the text descriptions sits on a Web browser somewhere and so does the video resource. How do you go from there to having it presented? Silvia. Cheers, Silvia. > > > Peter > > > On 7/6/2011 5:23 PM, James Teh wrote: > > On 7/07/2011 9:44 AM, Silvia Pfeiffer wrote: > > I've not seen any cloud-based solutions for text descriptions. > While such an approach is possible, it relies on special services > offered by providers and is therefore not something that a Web browser > can rely on for having their content rendered. > > It also smells of non-standard to me, as well as requiring reliance on > external services. > > > I do indeed believe that screen reader handling of text descriptions is > the best way forward. > > I agree for the most part, though I'm still not so keen on the pause > while description is catching up behaviour. Part of this is > design/implementation concerns; I'm very concerned about this tight > interaction between the screen reader and the system. Generally, a > screen reader is fairly passive in terms of its affect on the > application without user action. Also, it could sometimes be extremely > disruptive for the user. > > > For non-deaf/blind users are there significant advantages of Braille > over TTS such that TTS would not be a viable solution for providing > text descriptions to a Braille user? > > It could actually be useful if the user doesn't want the disruption to > the audio that audio/TTS description causes. Braille could be a nice way > of silently accessing the descriptions. However, as I noted before, I > think a scrolling transcript is the best way to do this. The user can > always disable scrolling if they wish or scroll back to read something > they missed. > > Jamie > > > > -- > [image: Oracle] <http://www.oracle.com> > Peter Korn | Accessibility Principal > Phone: +1 650 5069522 <+1%20650%205069522> > 500 Oracle Parkway | Redwood City, CA 94065 > [image: Green Oracle] <http://www.oracle.com/commitment> Oracle is > committed to developing practices and products that help protect the > environment > > _______________________________________________ > Accessibility-ia2 mailing list > Accessibility-ia2@lists.linuxfoundation.org > https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2 > >
<<green-for-email-sig_0.gif>>
<<oracle_sig_logo.gif>>
_______________________________________________ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
