Description: Ladies and gentlemen! I'm visually impaired, almost blind, and therefore I use assistive technology (JAWS and ZoomText). Unfortunately I had to realize that cursor-tracking in Writer does not work. This means: When a screen-magnifier (ZoomText, Windows-Magnifier, etc.) enlarges my screen, of course NOT its whole content is visible. Therefore it's necessary that various elements (e.g. menu-items, mouse-pointers, cursors, etc.) are tracked by the magnifier; so, this part of the screen "jumps" properly to that point where something (e.g. the cursor) is moving. But unfortunately this does NOT work in writer. At the beginning I may see the cursor, but when I start writing, it disappears on the right, and I have to go by mouse forward, which is not a really efficient and convenient solution. The selector in Calc is tracked very well, but not the writing-cursor in Writer. I tried it with the Windows-Magnifier and ZoomText, and this problem occurs with BOTH programs. But a writing-cursor in a dialog-box or in other programs will be tracked quite well. If this issue could be solved in future versions,... I guess a lot of visually impaired people would be thankful. Also we would be happy to have a well usable alternative to MS-stuff. OK, so far, hoping the best and remaining with best regards from Austria Florian Keckeis Steps to Reproduce: Feel free to try with both. Windows-Magnifier is there, and ZoomText can be downloaded and tried for free (40 min. demo). Enlarge to a higher level (e.g. 15 times), just to see the problem REALLY clear. And then write a piece of text in Writer and look how the cursor behaves,... and you'll see what I mean. Actual Results: No cursor-tracking with screen-magnifiers in Writer Expected Results: A well-working cursor-tracking for magnifiers. Reproducible: Always User Profile Reset: No Additional Info: MUCH too special. A normal help would NOT provide anything for this.
+1, valid requirement to support Assistive Technology tools provided by os/DE
Would like UX-advise work-up of where we could make use of vcl/svx view port movements following the edit-cursor position. As here (bug 155352) for following cursor movement for screen magnifier AT. But likewise for search/find actions and spell check/grammar check (bug 105610). IIUC Jim R. has actually done a lot of the core work (vcl & svx repositioning of canvas and edit cursor focus) already for the Navigator movements--would think that placing the view port at high magnification under edit cursor movement control would be achievable now. Seems feasible to link view port with spell/grammar check results. And would imagine the same ability pan view port to keep quick find / find & replace search results at the same relative position on the display as moving between results. We could certainly use it for LO UI needs, but view port pan following edit cursor would certainly provide an a11y boost to os/DE provided screen magnifiers.
Don't understand what UX can contribute but adding Michael as the a11y expert.
(In reply to Heiko Tietze from comment #3) > Don't understand what UX can contribute but adding Michael as the a11y > expert. Question for UX/Design There are a number of ways we could structure the viewport movements for use at high magnification. An Assistive Technology tool, but also of utility for general use. A simple checkbox to enable the AT from Tools -> Options -> Accessibility would of course be a minimum for the viewport to track the *text edit cursor* What makes sense for controlling the view ports of the document canvas at zooms sufficient to allow the edit cursor to pass out of the view port? Centering the view port onto the results during a find or spell/grammar check movement is an obvious requirement. As compared to current haphazard way canvas is repositioned now and that can place the result--out of view--when using the AT. It is less clear exactly how to handle view port during text input--when to pan? 2nd ICU word bound, 3rd? Too soon and it becomes annoying, too late and it is not effective AT as the cursor can pass out of view of the magnified portion. Also, how to adjust viewport relative to *drawing cursor* movements. Or movements of entire drawing objects? Those would have the same issues with how frequently to recenter, and what would trigger? Should the LO control of the viewport respond to the zoom factor the user chooses for their os/DE magnification? Somehow dynamic, or require a value entry when toggling the AT control? And where else in the UI for general use? Should it be provided globally on the Tools menu, or from the affected dialogs/toolbars? Lots of potential input needed to guide any dev's effort, and not just the AT facet. So, better to have the work (affected LO modules, viewport movements over the canvas, triggers, and locations for the controls) scoped out under UX-advise in advance.
Cursor-tracking works fine on Linux with GNOME Magnifier (s. e.g. the commits related to tdf#149952 to make this work on Wayland), but I can confirm it doesn't work for me with LO and Windows Magnifier on Windows. IIUC, what happens on Linux is that LO sends caret-changed events and the magnifier then queries the current caret position + then the corresponding coordinates and takes care of moving the scaled view to the corresponding place, so LO does not have to do that by itself. I don't have any experience with Windows Magnifier etc., but suppose it should be similar there in general. From a quick look, it looks like notification of changed cursor/caret and the methods to query the current position appear to be implemented in the winaccessibility module in LO, so it might need further analysis why it doesn't work. In a quick test, the cursor was properly tracked with Windows Magnifier when using Notepad++ instead of LO. But then, the fact that Windows Magnifier is closed source makes analysis more difficult, since it's not possible to see what happens on that end. (And it might be possible e.g. that something would have to be changed in Windows Magnifier, e.g. it could be that it only supports UIA events, but not IAccessible2, which LO uses,...). Is there possibly any open source alternative that is known to behave similarly (cursor-tracking works with other apps, but not LibreOffice) that could be used for the analysis instead?
Created attachment 187454 [details] Screencast Windows with LibreOffice vs. MSO The magnifier zooms in at the cursor position but typing does not focus on the cursor. The same happens when the entered text goes beyond the visible area. In contrast, MSO does focus the cursor on input and keeps it visible while typing. A zoomed view (without magnification) scrolls left/right and up/down if the cursor moves out of sight. And in combination with the magnification it becomes really tricky (the cursor must not and does not for MSO/Win remain static meaning input and arrow actions are send to the scrollbars). I hope this will be solved by the OS/DE. I don't think we should add an option. If the viewport has a magnification this needs to work out of the box. If really necessary I can follow the idea of tools > options > accessibility.
(In reply to Heiko Tietze from comment #6) > I don't think we should add an option. If the viewport has a magnification > this needs to work out of the box. I agree. As written above, this requires proper handling on the magnifier side as well (which may or may not be in place yet). For further analysis/experimenting with the magnifier API on Windows (e.g. to write an own sample one, since the system one is not open source AFAICT), this might be helpful: Windows magnification API doc: https://learn.microsoft.com/en-us/previous-versions/windows/desktop/magapi/entry-magapi-sdk magnifier sample: https://github.com/microsoft/Windows-classic-samples/blob/main/Samples/Magnification/cpp/Windowed/MagnifierSample.cpp