Steps to reproduce: 1. Create a new Writer document and write "Hello world" 2. Enable record changes and show changes 3. Change "Hello" into "Goodbye cruel" and make "world" bold 4. Use Accerciser to examine the accessible paragraph with the changes Results: 1. Visually, there is a vertical bar to the left of the changed paragraph. But there seems to be no way for ATs to identify the paragraph has changes. 2. If you hover the mouse over the deleted, inserted, or formatted text, a tooltip provides sighted users information about the nature of the change, who made the change, and the time the change was made. None of this information seems to be exposed to ATs. 3. The accessible text is "HelloGoodbye cruel world" (which, when spoken by a screen reader, is confusing). Possible remedies: 1. Add an object attribute to the paragraph. The exact name-value pair can be discussed. But perhaps something like "has-changes" with a value of "true" or "false". 2. Because tooltip content is often exposed to ATs as the accessible description of an object, doing so for changed text seems like it would be a reasonable solution. HOWEVER, the tooltip content applies to a span of text; not the entire paragraph. So if we want to expose the tooltip as an accessible description, then each span of changed text would have to have a corresponding accessible object (presumably a child of the containing paragraph). 3. Assuming each span of changed text is exposed as an accessible object, adding an object attribute like "change-type" with values like "insertion" / "deletion" / "formatting" would make it possible for ATs to customize what they present so that the presentation makes sense to the user. Note: At the moment, the accessible text attributes do not reflect the yellow color of changes or the strike through attribute of deletions. I have mixed feelings about whether or not that is correct. But I also think that exposing those text attributes is not the right way to remedy the problems I listed above (i.e. it's a separate issue).
(In reply to Joanmarie Diggs from comment #0) > 4. Use Accerciser to examine the accessible paragraph with the changes How can I find it with Accerciser? Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information.
> Results: > > 1. Visually, there is a vertical bar to the left of the changed paragraph. > But there seems to be no way for ATs to identify the paragraph has changes. This part seems to have been addressed via text attributes. (Interface Viewer -> Text(Editable)). So this part is no longer a problem. > 2. If you hover the mouse over the deleted, inserted, or formatted text, a > tooltip provides sighted users information about the nature of the change, > who made the change, and the time the change was made. None of this > information seems to be exposed to ATs. I'm no longer seeing the tooltip. So it's hard to illustrate the absence of accessible information for something which is absent. :) The nature of the change is in the text attribute now (part 1 above). But if the author who made the change and the time the change was made is something that sighted users can see, what I would suggest you do to reproduce it is use the interface viewer to explore all aspects of the paragraph (expand accessible, expand hypertext, expand text, ....) and find it. If you thoroughly explore all possible things in Accerciser related to the paragraph and cannot find the author and time, then odds are Orca won't be able to find it either. > 3. The accessible text is "HelloGoodbye cruel world" (which, when spoken by > a screen reader, is confusing). You can see this in the Interface viewer by expanding Text (Editable).
(In reply to Joanmarie Diggs from comment #2) > You can see this in the Interface viewer by expanding Text (Editable). So what to do, if it is greyed out and Not implemented? Do I have to be in some specific node of soffice? If yes, how to find it? Accerciser interface seems somehow hopeless. There is no way to locate a wanted node by searching for content like "world".
(In reply to Buovjaga from comment #3) > Accerciser interface seems somehow hopeless. There is no way to locate a > wanted node by searching for content like "world". Ok, now I am a wiser after reproducing another report. The key to an uncluttered Accerciser experience is to launch it after creating everything in LibO. Regarding the authorship information: the tooltip seems gone, it is true. Sighted users can use Edit - Track changes - Manage changes to view author info. I went to examine it in Accerciser and it does show the info as node names (type table cell). Joanmarie: do you think this is "worksforme" now? For future testers: In the node view you should have: Untitled (frame) -[no title] (panel) --Untitled (root pane) and then a whole bunch of nodes. Now look at the panel with 3 children. It has a child that is "scroll pane". This scroll pane has a child of the type "document text". This document text has a child of the type "paragraph". 64-bit, KDE Plasma 5 Build ID: 5.1.2.2 Arch Linux build-1 CPU Threads: 8; OS Version: Linux 4.5; UI Render: default; Locale: fi-FI (fi_FI.UTF-8)
Good day, First: please excuse my English, I'm Dutch. I can imagine that this question/bug/enhancement tip is already asked a million times by other editors, but I couldn't find it. The one reason for using MS Word is because of the track changes feature. All my clients (publishers) ask me to edit manuscripts using this feature. When using it, it is crucial that the changes 'overwrite' the original text: only a red stripe next to the edited line indicates a change, and of course I can make it visible when desired ('show all changes', in Dutch). After using Libre Writer for the first time, and trying out the track changes feature, a message warned me of possible slow down. What!? And indeed, typing while using track changes, feels like my keys are pressing through thick sirup. Could you please offer a track changes option that doesn't slow me down? I'm forced to keep using Word untill this is fixed. Thanks! Rob Steijger (www.fzeven.nl)
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Joanmarie Diggs, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug