Description: I had posted the problem on Ask LibreOffice here - https://ask.libreoffice.org/en/question/86163/libreoffice-writer-display-found-wordphrase-in-a-constant-position-on-the-screen-and-change-highlight-colour/ But was told it would be better to file a bug, as an enhancement. This is an edited version of that post - I've been working with someone who has very limited sight who describes their vision as being 'a bit like looking through a keyhole into a smoke filled room'. Their process for writing is to touch-type a number of paragraphs or pages, and then, using macOS's built in 'text-to-speech' function, listen back to whatever they just wrote until they reach a word or phrase they're not happy with. They then search for said word or phrase using the search function in LibreOffice Writer, and attempt to edit it. The problem is that they find it very difficult to locate the searched words on the screen, as they will be in a different position each time, and the transparent blue highlighting is not bright enough for them to clearly see. A solution might be to have an additional window that always appeared at the center of the document when searched words were found, containing the the words that were were searched, highlighted in a bright red (for example), with some context either side (5 words or maybe a sentence each side). I've attatched a rough diagram of how it might look. I've looked into developing these features for Writer myself, in the form of an optioal extension, and while i think it could be doable, it's not an area I have a lot of knowledge about. Any help is greatly appreciated as this is hopefully the last step before they can get back to a point where writing isn't just seriously frustrating. Steps to Reproduce: 1. Search for word(s) using Writer find function (CTRL + F) 2. 3. Actual Results: Found word(s) (if any) are highlighted in a light transparent blue, at whatever point they are positioned on the page. Expected Results: Found word(s) (if any) are highlighted in a bright red (or a chosen colour) and are contained within an editable text window, along with some context either side (5 words or maybe a sentence each side), that is always positioned at the center of the document. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Created attachment 130761 [details] Rough diagram of editable central text window and highlight colour
Yes, a very worthy accommodation for accessibility. It would require a zoom to selection with pan and scroll of document canvas to have edit cursor focus follow the spell check and grammar hints. Of course, would be distracting as default. So would probably need to be toggled active from the Tools -> Options -> Accessibility panel, and probably should provide setting for the zoom level. Also, would think providing an ability to set the view to high-contrast or apply alternate color scheme would provide correct a11y interface to make this functional. Other UX input?
(In reply to V Stuart Foote from comment #2) > Other UX input? Part of my proposal to rework the Navigator is to have a special section for comments- and likewise search results. This would change a lot. Right now she has to press ctrl+F to search for "night" (example from dummy text dt+F3), escape to leave the quick search, enter "day", and search again. Shouldn't we support the interaction and, for example, put the focus at the first (highlighted) occurrence allowing direct editing? Independently, I could imagine that the OS has means to follow the view and to zoom parts.
(In reply to Heiko Tietze from comment #3) > Independently, I could imagine that the OS has means to follow the view and > to zoom parts. That would be the general case and would have some use. But enhancement here requires new vcl/sfx methods to link the automatic spell check hits on canvas to a zoom and scroll/pan capability. This is very specific control of the document canvas we could/should implement for a11y support.
(In reply to V Stuart Foote from comment #2) > Yes, a very worthy accommodation for accessibility. It would require a zoom > to selection with pan and scroll of document canvas to have edit cursor > focus follow the spell check and grammar hints. > > Of course, would be distracting as default. So would probably need to be > toggled active from the Tools -> Options -> Accessibility panel, and > probably should provide setting for the zoom level. Agree. > Also, would think providing an ability to set the view to high-contrast or > apply alternate color scheme would provide correct a11y interface to make > this functional. Hadn't thought of this, good idea.
First, thanks for the report. Accessibility enhancements are important to make life and work for all people easier. (In reply to V Stuart Foote from comment #2) > Of course, would be distracting as default. So would probably need to be > toggled active from the Tools -> Options -> Accessibility panel, and > probably should provide setting for the zoom level. Thought the same that such feature should not be the default. > Also, would think providing an ability to set the view to high-contrast or > apply alternate color scheme would provide correct a11y interface to make > this functional. Isn't the contrast aspect of this report part of OS settings? If so, the highlighting and text selection colors will be influenced by such a11y setting I assume. Generally to change the selection color from lightblue to e.g. red is no good idea as this color shouldn't be too intrusive. Maybe fixing Bug 92303 will improve the situation (inverting color was suggested in Bug 92303 comment 3).
(In reply to francis.binnie from comment #0) > Steps to Reproduce: > 1. Search for word(s) using Writer find function (CTRL + F) > 2. > 3. > > Actual Results: > Found word(s) (if any) are highlighted in a light transparent blue, at > whatever point they are positioned on the page. I'm testing LibreOfficeDev 6.1 on GNU/Linux with my screen magnifier software (EZoom) and when I follow the steps you describe the screen magnifier focus on the result. Does your friend use a screen magnifier ? Best regards.
Created attachment 140206 [details] Screenshot of selection with LibreOfficeDev 6.1 GTK2
Created attachment 140207 [details] Screenshot of selection with Pluma (text editor) 1.8 GTK2
(In reply to Thomas Lendo from comment #6) > Isn't the contrast aspect of this report part of OS settings? If so, the > highlighting and text selection colors will be influenced by such a11y > setting I assume. Generally to change the selection color from lightblue to > e.g. red is no good idea as this color shouldn't be too intrusive. Maybe > fixing Bug 92303 will improve the situation (inverting color was suggested > in Bug 92303 comment 3). It should follow the OS settings indeed but it's not the current behavior on LibreOfficeDev 6.1 GTK2 on Debian Jessie. See my related screenshots. I'll test with GTK3 also. Best regards.
(In reply to Alex ARNAUD from comment #10) > I'll test with GTK3 also. I can reproduce exactly the same behavior on Debian Sid, GTK 3.22.28, LibreOffice 6.0.1.1. I've set the theme to "High Contrast". It's the contrasted theme provided by the GNOME Foundation as a part of GTK3. Best regards.
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.