Here's what I think: We need to just go ahead and do something. If the graphical screen reader developers really were highly motivated to support braille well then, over the last several years, they'd have had some ideas and, at least once or twice, would've raised the issue with us. Also, if we hold a long series of committee meetings regarding what should be done, interest will, as usual, fade away and the job won't get done.
My opinion is that we simply need to start, and, as we go, using our improvements as they come along, we'll, slowly on, learn what else we need to do. Let's just get started, and then work in a way that invites lots of testing by our users, starting from very early on, so that we'll discover what else to do and also so that we won't start moving in a wrong direction. This, as may have gone silently unnoticed, is the very approach that has gotten brltty to where it is today. Our key tables have contexts (those who know about key tables know what I'm referring to). This means that we don't even need a new set of key tables - we just need new commands which are bound within a new, persistent, GUI context, and a way for BrlAPI to read commands in that context. Then, of course, we need to know what the new commands need to be. Perhaps someone wouldn't mind looking at Orca and NVDA in order to make a list of what bindable actions each of those screen readers offers. People who have access to JAWS, Window Eyes, Dolphin, etc could also provide lists of the bindable actions that those screen readers offer. We could then review all of these action lists with a view to determining what others have found the requirements to be. We could also imagine what an initial base set of useful actions might be: For hierarchical navigation: go to root node go to first child node go to specific child node (using a routing key) go to next sibling node go to previous sibling node go to parent node For positional navigation: go one node to the right go one node to the left go one node up go one node down go to the leftmost node in this row go to the rightmost node in this row go to the topmost node in this column go to the bottommost node in this column General commands: describe this node etc We should also be brave enough to, wehre necessary, test our own changes to Orca, and then, if they work well, submit them to Orca as patches and/or pull requests. This, for example, could already be done in order to resolve the issue regarding skipping of identical lines and blank ends of lines. These are just my own ideas regarding how to tackle the improving of braille navigation within graphical environments. Yes, they call for action rather than just talk, which may be why others will strive to come up with better ones. That's okay, though, because, as it should be, I only intend these ideas to be a startying point and very much do welcome better ones. -- Dave Mielke | 2213 Fox Crescent | http://Mielke.cc/ Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/ EMail: [email protected] | Canada K2A 1H7 | The Bible is the very Word of God. _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://brltty.com/mailman/listinfo/brltty
