> When the caret is invisible the location has to be considered the > current focus. I certainly hope the AT is not depending just on the > caret, but is following the focus as well.
Some classes of AT's, such as a screen reader, care about not only what object has focus, but other information about that object as well. For example, which item(s) are selected in a list, what the value of a slider is, and where the caret is in a text object. Will > > The point about clicking was that it is just one way this invisible > caret is moved. About the only affect the invisible caret has is that > the next find command will start finding text from there. > > - Aaron > > > Willie Walker wrote: >> If an assistive technology is depending upon the caret location to >> know >> where the user's current location is in the document, then not >> emitting >> this information is bad. In addition, clicking is usually only an >> option for people who can use the mouse, so cannot necessarily depend >> upon that as a solution. >> >> So, at first blush, I think you should emit the caret movement event. >> >> Thanks! >> >> Will >> >> On Thu, 2006-06-22 at 09:13 -0400, Aaron Leventhal wrote: >> >>> [Trying to send one more time] >>> >>> Firefox sometimes moves the caret even when it is not visible. For >>> example, if the user tabs, the caret is moved right before the next >>> item. If the user clicks on text content, the caret is moved there. >>> >>> I am planning to suppress caret move events when the caret is hidden. >>> Make sense? >>> >>> - Aaron >>> _______________________________________________ >>> Gnome-accessibility-devel mailing list >>> [email protected] >>> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel >>> >> >> >> _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
