Multiple selection points and focus

There are many places in the editor where the  current focus does not correspond to the insertion point. Magnifiers and screen readers generally track the insertion point and/or the focus.  They can also track the mouse pointer, although this is usually tiresome with screen readers.

I find it visually confusing if, for instance,  segment 6 is active (highlighted in blue) and I double-click in segment 7, which does not become active on double-clicking, although the insertion point does move, because typed text is accepted in segment 7. If I am using concordance, it is perfectly possible for segment 6 to be active, for the entire target text of segment 5 to be selected (because I wish to listen to it with text-to-speech) and for a separate  word in the source of segment 6 (or any other segment)  to be highlighted because I wish to look it up in concordance.  It is often entirely unclear to me where the insertion point is at any given time, particularly if it is not in the active segment. Clearly, this is a problem specific to a visually impaired user  who nevertheless primarily works visually.

This problem is exacerbated  when the focus and insertion point are, for instance, in the Translation Results pane  and multiple other positions are highlighted or selected in the editor.

More problematic is the fact that the focus does not move when I perform a search. The search target is highlighted by a red box, but neither the focus nor the insertion point moves, so this is not tracked by the magnifier or by a screen reader. For me, the highlighting is so subtle that I cannot see where it is,, and even when I do find it, I have to use the mouse to move to the segment  in order to read it with text-to-speech.

A similar example of poor behavior with the focus and insertion point is the Track Changes function. If I have a document with a number of tracked changes, I can move to the next tracked change by pressing F9. This does not, however, activate the segment in which the change occurs. Pressing Ctrl+F9 to accept the change has no effect. I first have to click in the segment, find the change again and then press Ctrl+F9.

I have already referred to another example of this behavior in another post, namely that  when a user uses the functions of the View ribbon to move, for instance, to the Translation Results pane,  the insertion point and focus are not moved. Neither the screen reader nor the magnifier track this change of position.

All of these issues represent massive hurdles to screen readers, which attempt to identify and track the focus and the insertion point.  If the point of interest (at which the user wishes to read text) is somewhere other than  the insertion point, the screen reader simply does not know where to start.

1 Replies Latest Replies: 29 Apr 2016 6:30 AM by Paul
  • Improvements in the integration API and work being carried out at the moment by a third party developer working with JAWS might show some improvements in this area.