[BRLTTY] The braillists forum and an article about reading in braille

[Mario Lang]

Sébastien Hinderer <Sebastien.Hinderer at ens-lyon.org> writes:

> Are you in a way saying that it would be helpful also for text
> application to be able to export their structure somehow, as graphical
> ones do?

No, actually not.  The idea of speech-enabled applications goes a little
further.  There is the counterargument of "ghetto-applications" lurking
in the dark corners, but lets just ignore it for a while so that I can
make my point.

In most cases, a screen reader has to do guesswork to figure out how to
pronounce and present content correctly.  Think about dates, times, text with mixed
languages, destinguishing between tabs and spaces, mathematical
formulas, musical notation, you name it.  Widgets did help a little to
provide some generic abstractions a screen reader could use as a hint
about the actual content and how to interact with it.  But UI design
isn't stopping, and things presented on-screen are getting increasingly
complicated.  The new big thing in web design for instance is the HTML5
canvas.  Yes, you can now draw arbitrary stuff on a canvas with
JavaScript.  Wonderful for all sorts of things.  But the absolute killer
for any sort of classical screen reading.
Now the question is, which abstractions or annotations do you create?
How do you enrich your abstract widget tree such that the screen reader
can make most sense of a hyper-modern application which, say, is dealing
with math and music?
While the effort to enrich the widgets with more accessibility is
definitely worthwhile, certain applications will likely only work if
they start to build a screen reader into themselves.  The app has all
the context required to do a good job.  This has been tried in the past,
with varying success.  Think about IBM Homepage reader, which was really
quite cool for the time.  But it flopped for the reason given at the
beginning of this mail, it was a ghetto-application.  Built especially
for blind users.  However, what T.V. Raman started with Emacspeak doesnt
have that issue.  Emacspeak is an extension (sort of a plugin) written
for a very extensible editor.  So the screen reader is built into the
application itself.  No need to define external interfaces, no need to
cramp new stuff into vaguely fitting models.  Still much work to
actually make things work smoothly, but now you have full access to
everything.  There is no artificial barrier between the "screen" reader
and the application.  Everything the application "knows" the "screen"
reader can figure out.  No need for weird heuristics anymore.  You have
all the data type and metadata information at your disposal.

Of course, speech-enabling every application manually is a insanely huge
task which will never get done.  But it make sense to look at the
landscape of extensible programs and maybe pick a few which might
benefit from screen-reading built-in.  Emacs is certainly a good
example of a success-story for this.

> I guess the so-called widgets would be a bit different, may there may
> be something to think about there...
>
> But this wouldperhaps be defeated by the fact that text-mode
> applications may be more diverse than graphical ones, in the sense that
> graphical ones use one toolkit among a few, which is not so in
> text-mode...

GUI apps are also quite "diverse" these days.  Custom widgets (which
lack proper accessibility support) are all over the place.

-- 
CYa,
  ⡍⠁⠗⠊⠕