Re: A question on Screen Reader Speed Standards
- From: "qubit" <lauraeaves@xxxxxxxxx>
- To: <programmingblind@xxxxxxxxxxxxx>
- Date: Thu, 10 Dec 2009 07:34:36 -0600
Jaws 11 uses 2 numbers -- the first is some inexplicable number that is
probably the one used by the synth. The other is percent -- of what I'm not
sure -- perhaps the the percent of distance between the lowest and highest
speed setting for that synth. Mine currently says "112, 65%". Depending on
what I'm reading I can push it up to 75 or even 80 or more for familiar text,
but I usually leave it at 65.
Now really, does anyone listen to speeds over 80 for general reading? I have
heard claims. If they can, perhaps my hearing aids are getting in the way, or
perhaps they are not comprehending what they are reading...*smile* I aim for
full or near full comprehension.
Happy listening.
--le
----- Original Message -----
From: Chris Hofstader
To: programmingblind@xxxxxxxxxxxxx
Sent: Thursday, December 10, 2009 7:12 AM
Subject: Re: A question on Screen Reader Speed Standards
JAWS uses the actual speech rate setting as provided by the synthesizer. So,
for Eloquence, it's a value that is only meaningful to it and your ears. Other
synths use WPM or some other fairly arbitrary system like Eloquence.
I can't recall which year it was but we did a JAWS release that used a new
Eloquence wpm feature. The setting was miserably flawed and the EtI guys
pulled it out and we all returned to their internal scale.
WPM is really hard to get right for a variety of reasons, especially when a
screen reader sometimes sends as little as a single syllable and other times a
line of text or a full sentence. If the synth was used to read longer pieces
with a more predictable pattern, wpm would probably be a bit easier but as
screen reader users need to hear every different typeof chunk of information,
prediction becomes very hard.
I've noticed that the "Alex" voice on Macintosh does some fairly clever word
prediction to create an illusion of being faster than it really is. It's a
nice voice but when it gets the word prediction wrong it can be very confusing
as one doesn't know if he misspelled, mistyped or simply used the wrong word.
It doesn't make these mistakes often but I wish I could turn the feature off
while I'm editing and back on for reading long documents.
cdh
On Dec 9, 2009, at 4:37 PM, The Elf wrote:
Andreas,
I have no clue what jaws rates its speech rate on, especially since it
changes as you use the radio button to change it, flipping between two slightly
different numbers that make no sense to me what so ever.
my thoughts, yes make it a standardized method, and use the more universal
WPM rating, at least that one makes sense!
good luck,
elf
proprietor, The Grab Bag,
for blind computer users and programmers
http://grabbag.alacorncomputer.com
Owner: Alacorn Computer Enterprises
"own the might and majesty of a Alacorn!"
www.alacorncomputer.com
----- Original Message -----
From: Andreas Stefik
To: programmingblind@xxxxxxxxxxxxx
Sent: Wednesday, December 09, 2009 9:26 AM
Subject: A question on Screen Reader Speed Standards
Hi folks,
I'm working right now on trying to build up our cross platform speech
engines for the Sappy project and am trying, specifically, to get NetBeans to
store custom preferences related to screen reader speed. On Mac, we basically
just pass a flag to the TTS engine with a number, which, I suspect, is words
per minute, although I'm not completely sure. On PC, things appear to be quite
different and I'm not sure about all of the open source, and other, solutions
out there (insert your favorite technology here).
My question is, what would people suggest for standardizing the numbers
for speed of reading we use for screen readers across all platforms? For
example, does each screen reader everywhere measure speed in a different way?
Should just put everything in words per minute and not worry about it,
translating any screen reader that doesn't comply through some kind of
calculation (if possible?)? Should we just standardize through some arbitrary
metric, like 0 is the slowest and 1 is the fastest, then test everywhere to
make sure those settings are "reasonable" and that the user's system
preferences are not disturbed?
To be clear, remember that our tool has to, ultimately, be compatible
with every kind of screen reader, and should still work for the blind even if
no screen reader is present (or if the screen reader doesn't work well at all).
That's why I am asking,
Thoughts are welcome,
Stefik
Other related posts:
