Sébastien Hinderer <sebastien.hinde...@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, ⡍⠁⠗⠊⠕ _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty