https://bugs.documentfoundation.org/show_bug.cgi?id=88762
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected], | |[email protected] --- Comment #9 from [email protected] --- 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. -- You are receiving this mail because: You are the assignee for the bug.
