Bug 88762 - Orca incorrectly announces paragraph indentation when using the get attributes "orca+f" keyboard shortcut
Summary: Orca incorrectly announces paragraph indentation when using the get attribute...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.5.2 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: accessibility
Depends on:
Blocks: a11y-Linux
  Show dependency tree / graph
 
Reported: 2015-01-23 21:33 UTC by am_dxer
Modified: 2026-03-11 16:52 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:

Attachments
random test document (13.31 KB, application/vnd.oasis.opendocument.text)
2016-05-06 13:29 UTC, Aron Budea 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description am_dxer 2015-01-23 21:33:21 UTC 
When indenting the first line of a paragraph through the paragraph settings dialog in the format menu, orca says the text is indented when I use the "orca+f" keyboard command even if I am not on the first line of the paragraph. Orca should only announce this indent when on the first line of the paragraph.
Comment 1 Robinson Tryon (qubit) 2015-12-10 03:37:46 UTC Comment hidden (obsolete)
Comment 2 Aron Budea 2016-05-06 13:29:54 UTC 
Created attachment 124882 [details]
random test document

Reproduced. Attaching a sample document.

In Pararaph settings I set first line indentation to 0.28". I also set before text indentation to 0.1".
This is what the screen reader says for characters in any line, pressing Orca-F: "Size 12, Family Name Liberation Serif, Indent 7.11 mm, Paragraph Style Default Style" etc...

I'm not entirely sure how it's supposed to work, is it fine that before text indentation is disregarded? It certainly announces the first line indent for each line (the indent is announced in lines after a line break, too).

Another interesting thing to note is that while in this particular installation I used imperial units to specify the indentation, the reader announces it in metric. Is that a bug, or separate settings?

OS: Ubuntu 15.10

LO Version: 5.0.5.2
Build ID: 1:5.0.5~rc2-0ubuntu2
Locale: en-US (en_US.UTF-8)
Comment 3 QA Administrators 2017-05-22 13:38:58 UTC Comment hidden (obsolete)
Comment 4 Alex ARNAUD 2017-05-30 15:48:35 UTC 
Dear all,

The issue is still present on LibreOfficeDev 5.5 from 2017-05-28.

Best regards.
Comment 5 QA Administrators 2018-10-02 02:54:51 UTC Comment hidden (obsolete)
Comment 6 QA Administrators 2020-10-02 03:51:10 UTC Comment hidden (obsolete)
Comment 7 Chris Sherlock 2022-06-30 12:57:44 UTC 
I can confirm that Orca only reads out the first line indentation on 7.11mm, but it does *not* give the before text indentation. 

Reproduced in LibreOffice 7.3.2
Comment 8 QA Administrators 2024-06-30 03:15:00 UTC Comment hidden (obsolete)
Comment 9 cwendling 2026-03-11 16:50:05 UTC 
Still the same in LODev26.8.0.0alpha0 and Orca from Git, but...

(In reply to Aron Budea from comment #2)
> I'm not entirely sure how it's supposed to work, is it fine that before text
> indentation is disregarded? It certainly announces the first line indent for
> each line (the indent is announced in lines after a line break, too).

I don't know what users really expect here, we'd need input on this I guess.  I see however (in Accerciser) that LO *does* report all three of "before text indent", "after text indent" and "first line indent", respectively as "left-margin", "right-margin" and "indent".

So I see a few options:
1. don't change anything, and let the screen reader read whatever values it likes.
2. report the effective indent for the paragraph, that would be... "before text indent" + "first line indent" maybe?
3. report the effective indent for the visual line at the current position (like above, but take the visual line into account, so on the first line it could be as 2, but on subsequent lines it would be "before text indent" alone).
4. like the above, but report this in addition to the actual values (possibly put the computed result in "indent", and the rest as different attributes.

IMO, it mostly depend on the use case, but the current situation isn't too bad but for knowing the *effective* indentation of the line.

There also is a technical limitation for all variants where the visual line is taken into consideration, because the accessibility API is twofold: default attributes, and range attributes.  Default attributes are usually not announced without asking for them explicitly -- e.g. if you move over the text, you won't be presented with the default attributes, but only with the range ones, which might include e.g. misspelling.  And default attributes are a property of the whole text portion (e.g. paragraph), not a range.
This means that there is no real way to convey a default attribute that changes in the middle of the paragraph, so we would have to make it a range attribute.  And so, we could either always get notified of the indent changing whenever moving through the text, or we'd have to have the screen reader play along by e.g. filtering out the "indent" attribute then.

Maybe the Orca dev has an opinion here.

But at any rate, the reason why the user want to hear out the indentation will play a large role here, because e.g. in a code editor what usually matters is the *physical* line indentation, not the visual one.  Here we're having a layout software as well, so maybe the needs are different though; but is the effective indentation the useful thing, or do we actually need the value of all the three settings?  In this case, it should either be presented by the screen reader, or we'd leave the user to inspect paragraph properties if they need finer info.  At any rate the three values *are* available, the question is whether they are presented correctly, and whether they are presented in a useful way to the user.

> Another interesting thing to note is that while in this particular
> installation I used imperial units to specify the indentation, the reader
> announces it in metric. Is that a bug, or separate settings?

I'd flag this as a bug (in how the value is rendered for presenting), as it should ideally be in a unit the user is comfortable with.  And although the metric system is the real answer (:grin:) conversion is not so trivial that everybody can use that interchangeably.
Hopefully it's an easy fix using the localized value taking the preference into account.  If we're out of luck, it's hard to retrieve the relevant flag in the stage the value is generated, but I kinda doubt it.