Trevor Saunders wrote: > imho doing this isn't a particularly good idea,
emacspeak, for example, is self-speaking and it works much more fluently than raw emacs plus a screen-reader. My particular case is my Perl CPAN module http://search.cpan.org/perldoc?Term::Clui which allows choice between a number of strings using arrow keys and return. The highlit choice is in reverse video, and therefore yasr users can't tell which it is. Also, when the highlight moves following an arrow-key or tab, Term::Clui has to rewrite both the previous no-longer-highlit item and the new highlit item; so both get spoken, which is unhelpful to the user. There's also the case dealt with by my little wrapper http://www.pjb.com.au/blin/free/quiet which can be used for noisy programs like wget or mplayer to automate the necessary switching-off and -on. > it seems somewhat rude to reach into the users screen > reader config and change it without them asking for it, Agreed, definitely; it's not a config-change. It's a real-time need, just like sending "\e[7m" to /dev/tty to go reverse-video. > it seems like a sub optimal design for $application to > know about all the screen readers out there and have > special code to try and make each of them be quiet. AIUI speakup and yasr are the important ones; I think e.g. the burden of incompatible user-interfaces (for which there are however good reasons) is more regrettable, and to more people, than one extra line in Term::Clui. Perhaps it would be more optimal to have One Perfect Screen-Reader, but that's a different universe. So I think there are legitimate use-cases. Regards, Peter Billam http://www.pjb.com.au [email protected] (03) 6278 9410 "Was der Meister nicht kann, vermöcht es der Knabe, hätt er ihm immer gehorcht?" Siegfried to Mime, from Act 1 Scene 2 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
