Issue 86078 - Caret position not being reported for Accessibility Issues
Summary: Caret position not being reported for Accessibility Issues
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 2.3.1
Hardware: PC Windows, all
: P4 Trivial (vote)
Target Milestone: OOo 3.x
Assignee: AOO issues mailing list
QA Contact:
Keywords: accessibility
Depends on:
Blocks: winA11y
  Show dependency tree
Reported: 2008-02-13 18:08 UTC by bitslayer
Modified: 2017-05-20 09:41 UTC (History)
4 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description bitslayer 2008-02-13 18:08:36 UTC
We are makers of accessibility software that works with most word processors 
and any other product that receives textual input.

Often times it is helpful for some users to be able to show them where the 
caret position is in the document.  In addition, the caret is typically used 
to indicate the kind of text input mode the user is in (e.g. insert or 

Because the caret graphic is used to indicate mode it is unwise and perhaps 
cumbersome to devise a way for the user to customize or enlarge the caret for 
low-vision purposes.  Thus one might consider using another program (e.g. 
Mouse & Caret Buddy) which will POINT to the caret and mouse. 

Moreover, one might need a word prediction program (e.g. SoothSayer) which 
will move a word option box close to where the user is typing.

In order for external programs to be capable of this, they must access the 
caret position through the Windows API.

It seems very trivial for the developers of the text-input module to include 
setting the caret position when the caret is moved.

Please consider making this change and announcing it to the general user 
population when the change is made.


Kevin S. Templer
Chief Software Architect of Accessibility Products
Applied Human Factors, Inc.
Comment 1 michael.ruess 2008-02-13 21:27:44 UTC
Reassigned to ES.
Comment 2 eric.savary 2008-02-14 00:29:41 UTC
@MI: please take over (Windows, Enhancement)
Comment 3 malte_timmermann 2008-02-14 10:28:38 UTC
MT->OBR: Think this should work once we have IA2/MSAA
Comment 4 nospam4obr 2008-03-12 15:25:26 UTC
@bitslayer: can you be more specific in which API you would expect OOo to expose
/ update the caret position ?
Comment 5 bitslayer 2008-03-12 17:39:51 UTC

I would be happy to explain.

In the assisitive technology world there is Active Accessibility but there is 
also just plain simple Windows API calls that can make your app more 

If you are using your own (or third party) text editor the problem is that it 
may not be setting the caret position that windows knows about.  The api call 
is SetCaretPos( x, y ); which is what your software, not mine, would call.  

My software would then be able to call GetCaretPos and know where the caret is 
in your app.  Some API experts might say "but you can't know the caret 
position of another app" which is true, in general, but under special 
circumstances another app CAN get that information.  Our software does it all 
the time with no problem from windows 3.1 to windows vista.

Another way is to implement the IAccessible interface which is COM.  There you 
would expose the caret position as well. 

Currently, however, my software does not use the IAccessible interface in all 
of our products (some do as they are newer and Active Accessibility while not 
new is now well defined and less buggy).

So I guess what I was asking for was if it would be possible to throw in the 
SetCaretPos( x, y ) every time you move the caret in the editor (or in any of 
the OOo products).


Comment 6 nospam4obr 2008-03-12 21:25:52 UTC
Thank you, this helped a lot understanding this issue. 

@pl : VCL seems to already call SetCaretPos under certain circumstances (active
Input Method Engine). Do you see a chance to always keep a Windows cursor around
and its position in sync with the internal one ?
Comment 7 malte_timmermann 2009-12-07 12:47:47 UTC
mt->pl: Please evaluate if SetCaretPos can be done, so we don't rely on some
future IA2 bridge, which would us also bring MSAA. If possible, try to fix in 3.3.
Comment 8 Rob Weir 2013-07-30 02:14:26 UTC
Reset assignee on issues not touched by assignee in more than 2000 days.
Comment 9 V Stuart Foote 2014-01-30 03:51:02 UTC
Possibly still of interest, but the MSAA/IAccessible2 1.3 API implemented provides for refined use of caret offset positioning in IAccessibleText and IAccessibleEditableText as text roles are refined.

Setting Resolved Obsolete. If still desired, should be resubmited within context of tailoring the IAccessible2 IDL assigned accessible text roles.