Bug 96487 - Expose tracked changes to ATs via accessible objects and attributes
Summary: Expose tracked changes to ATs via accessible objects and attributes
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard:
Keywords: accessibility
Depends on:
Blocks: a11y-Linux Track-Changes
  Show dependency treegraph
 
Reported: 2015-12-14 16:08 UTC by Joanmarie Diggs
Modified: 2017-10-01 01:13 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joanmarie Diggs 2015-12-14 16:08:10 UTC
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).
Comment 1 Buovjaga 2016-05-06 11:01:19 UTC
(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.
Comment 2 Joanmarie Diggs 2016-05-06 14:59:16 UTC
> 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).
Comment 3 Buovjaga 2016-05-07 10:25:26 UTC
(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".
Comment 4 Buovjaga 2016-05-07 10:55:38 UTC
(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)
Comment 5 rob.steijger 2016-07-14 10:18:18 UTC
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)