Removing public-html and wai-xtech and adding www-archive to CC.
On Sep 11, 2007, at 21:36, John Foliot wrote:
Henri Sivonen wrote:
I think that isn't quite the right question. I think the right
question is, what blind Web users would prefer to hear with the
constraint that another human can't be consulted and only software
heuristics can be used.
While I understand that we often use 'short-hand' when using written
communications, please remember that tools such as JAWS, WindowEyes,
Emacspeak (and other screen reading technologies) might also output
content
to yet more adaptive technology such as Braille Refresh bars.
I am unsure why you remind me of Braille bars when the context was
how JAWS manages to tar pit its speech engine by applying a heuristic
that is spectacularly bad and how I was saying that a heuristic
doesn't have to be that bad.
I would hope that what a Braille bar can ingest isn't considered to
limit the design of what sounds the aural facet can render. Is it?
As well, it
is totally conceivable that sighted users might want to have screen
reading
technology at their disposal as well: perhaps a user-agent in your car
dashboard that reads aloud directions to that great new restaurant...
Personally, I don't find it conceivable that anyone who doesn't have
to use screen readers would want to use them. But anyway, the
scenario you describe is out of the scope of "accessibility" as the
word has been applied here and is already successfully addressed by
dedicated multimodal navigation devices.
[...]
there is a toggle on/off for the @title attribute - the default
setting is off, thus relying on @title in lieu of @alt is a dangerous
presumption)
I think it is rather unreasonable to expect the author to guess what
the user has chosen to suppress even though the author takes the
trouble to make it available.
[... Lots of text about JAWS configuration snipped.]
I didn't understand the point you were trying to make with the JAWS
configuration options. I was merely pointing out that it wasn't hard
to come up with something that would be better than what the JAWS
does now according to Steve Faulkner's testing. Do you mean JAWS
could be configured to behave better than the testing article described?
I am asking what kind of improvements to screen readers are realistic
within, say, the next 7 years. As a software developer, I can assess
what kinds of problems are algorithmically solvable and I think I
understand market dynamics as they relate to server-side development
and to browser development. I don't understand the market dynamics of
screen readers, though.
Small market served by an even smaller corporate base. Essentially 2
mainstream front-runners (JAWS and WindowEyes) along with a few others
(including smaller, localized versions for foreign languages), plus
some
open source stuff that tries real hard but operates on goodwill and
free
time. The software is also fairly expensive, slowing the "upgrade"
path
considerably. Unlike browser upgrades (which can be frequent given
that the
software is free), many of the users I know will only upgrade their
screen
reading software when they upgrade their total system - which is
probably in
the 3 to 7 year range (system vendors might be able to tighten this
number
down a bit, but based on Microsoft's OS support plans, this would seem
roughly right)
What can be reasonably expected feature-wise after that update cycle?
Is it reasonable to expect JAWS to get fixed so that it won't try to
read strings that aren't suitable for reading as a fallback, for
example? Is it reasonable to expect JAWS to get support for new
constructs such as <figure>?
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
