[Kde-accessibility] Text-to-Speech from OOo and Browsers

[Willie Walker]

Hi Jonathan:

There are definitely several ways to approach this problem.  One way is
to require all applications to be "self voicing," meaning they drive the
speech synthesis engine directly.  The benefit of this approach is that
the motivated application developer might be able to provide a very
compelling user experience for the app.  The disadvantages of this
approach are that we often don't have application developers who are
motivated to provide accessibility (or, most likely, they just don't
have time) and the end user will typically end up with a different user
experience for each self voicing app they run into.

Another approach to this problem is to use an assistive technology such
as a screen reader.  A screen reader typically acts as an agent on the
system, observing what's happening on the desktop and then presenting
this information to the user.  It can do so via "screen scraping" and
other indirect methods, or it can use more modern methods such as
talking to an accessibility infrastructure.  On the Linux and Solaris
platforms, the predominant accessibility infrastructure is the
"Assistive Technology Service Provider Interface", or AT-SPI.  The
AT-SPI is supported by toolkits such as GNOME's GTK+, the Java
platform's Swing toolkit, and it's also supported by OpenOffice and
Mozilla.  The latest hot topic on this particular list is how to get it
into KDE's Qt.

The AT-SPI allows a screen reader to query the application for its
graphical object hierarchy and to register for a large variety of
events, such as changes in focus, changes in state, etc.  Furthermore,
the AT-SPI has provisions built into it to allow the screen reader to
query for text and text attributes, such as "what is the actual string
being displayed", "what font is being used", "what size is the font",
"what are the physical text boundaries", etc.  Using this information,
the screen reader can present the visual information of the application
in a non-visual way, such as speech and/or braille.  Screen readers also
sometimes take on the role of managing magnification of the display.

The benefits of a service-based approach (such as the AT-SPI) combined
with an assistive technology include:

1) By putting the AT-SPI into the toolkit, many apps become accessible
"for free" without requiring each application developer to become an
accessibility expert.

2) A screen reader can provide a more consistent user experience across
all applications.

3) It supports a culture of choice, where users can choose between
different assistive technologies.  For example, users now have the
choice between at least three different screen readers on the Linux
desktop.

I happen to lead the Orca screen reading project
(http://live.gnome.org/Orca), and I've also been working on
service-based approaches to accessibility for the X Window System since
the early 1990's, so I may be a bit biased here.  :-)

Related to the speech question, Orca currently uses the gnome-speech
system, which provides a service-based approach to accessing speech
synthesis engines.  Orca v1.0 will be shipping with GNOME 2.16 next
week.  As soon as GNOME 2.16 is out the door, we will be looking at
future support for things such as SpeechDispatcher.  I believe the
ultimate goals include providing a system-wide service for speech that
can be simultaneously used by different applications and works well
across things such as GNOME and KDE.  This would permit both the "self
voicing" and assistive technology camps to play well together on the
same machine.

Will

On Fri, 2006-09-01 at 13:25 +0100, Jonathan Duddington wrote:
> In article <200609011228.13904.ebischoff at nerim.net>,
>    Éric Bischoff <ebischoff at nerim.net> wrote:
> 
> > I think that we could all put our knowledge together and work an
> > accessibility support in OpenOffice.org.
> 
> A long time ago, on a different platform (Acorn/RISC OS), I wrote a TTS
> engine.  This was used by various application software such as word
> processors and email/news clients to provide features such as: 'speak
> text from cursor position onwards', and 'speak current paragraph', as
> well as 'speak selected text'.
> 
> I now mostly use a Linux/KDE system, but I don't find these features. 
> In OpenOffice.org and FireFox, if I want to speak text then I must
> first select it, copy to the clipboard, and then click on the KTTS
> panel icon and select "Speak from Clickboard" from its menu.  That is a
> lot more cumbersome than just a single click in the text window plus an
> icon-click or key-press to invoke a speak function in the Word
> Processor or Browser.
> 
> Selecting the required text can sometimes be tricky, and sometimes
> catches unwanted blocks of advert or sidebar text.
> 
> It has other disadvantages compared to a more speech aware application.
> 
> For example, a fact that text is a header line is lost when it's copied
> to the clipboard. Since it usually doesn't end with a punctuation mark,
> it's spoken run together with the following text as a single sentence. 
> The same applies to image captions in a browser.
> 
> A more aware application would enforce sentence breaks after header
> lines and paragraphs, and between list items, and around captions and
> other separate information.
> 
> It could also do useful things like vary the voice for italic or
> block-quoted text or the different quoting levels in an email. This
> reproduces in sound useful information which is available visually.
> 
> I use speech output for proof-reading and just generally listening to
> text which I often prefer to reading.  But I'm sure these points are
> even more important to people with poor vision. 
> 
> I'm not certain how the system works, but I believe that Speech
> Dispatcher acts as a common interface for applications that want to use
> speech output?
> 
> Do word processor and browser applications intend to provide these
> improved speech output features?
> 
> _______________________________________________
> kde-accessibility mailing list
> kde-accessibility at kde.org
> https://mail.kde.org/mailman/listinfo/kde-accessibility