Description: WHen applying formatting such as justifications, bold or anyother formatting changes, Orca screen reader does not notify me when I have applied the changes. Steps to Reproduce: 1. First start orca by pressing super+alt+s. 2. write someting like, this is a test and press enter. 3. Select the line and then press control b. 4. Orca does not say anything.1. 2. 3. Actual Results: Orca does not indicate formatting changes. Expected Results: Orca should announce when formatting changes take place such as bold on, bold off, Heading 1 applied, etc. Reproducible: Always User Profile Reset: Yes Additional Info: I am using ubuntu 25.1.10
I can confirm with Orca 49.6 Version: 24.2.7.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 4; OS: Linux 6.14; UI render: default; VCL: gtk3 Locale: nl-NL (nl_NL.UTF-8); UI: nl-NL Ubuntu package version: 4:24.2.7-0ubuntu0.24.04.4 Calc: threaded
Not(In reply to Darrell Bowles from comment #0) > Description: > When applying formatting such as justifications, bold or anyother > formatting changes, Orca screen reader does not notify me when I have > applied the changes. > > Steps to Reproduce: > 1. First start orca by pressing super+alt+s. > 2. write someting like, this is a test and press enter. > 3. Select the line and then press control b. > 4. Orca does not say anything.1. Unless anything specific is missing from the LibreOffice side, that to me sounds like logic that might best be implemented in Orca instead of LibreOffice. The NVDA screen reader on Windows for example announces such changes. It does so by intercepting the corresponding keyboard shortcuts, sending them to the application and then announcing changes to the state of the relevant UI (e.g. the "Bold" toggle button) in the toolbar if it happens within a certain amount of time after sending the keyboard events. I currently don't know whether that would be a viable approach for Orca as well (e.g. whether it has such infrastructure to handle locale-specific keyboard shortcuts...) or whether a different approach would make more sense there. @Joanie: Do you possibly have any thoughts on that? For reference: NVDA commits implementing the feature there. https://github.com/nvaccess/nvda/commit/46a343685247ed7d1adfb737716590ec4be456a0 https://github.com/nvaccess/nvda/commit/20bdb39e6f83ef87726817cb1bad31fa7b0f73cb https://github.com/nvaccess/nvda/commit/8827e60ad494f0c3121364f01301cde2305a784a https://github.com/nvaccess/nvda/commit/661da4949f0205e0e25ac8b40ee5c30bf294e37c
This used to work in Orca. Not by paying attention to shortcuts, but by paying attention to the toggle button state change. (Eventually Orca will pay attention to the actual attributes that change, but I've not gotten to that.) I'll update Orca to get the toggle button presentation working again. Thanks for the ping!
(In reply to Joanmarie Diggs from comment #3) > This used to work in Orca. Not by paying attention to shortcuts, but by > paying attention to the toggle button state change. (Eventually Orca will > pay attention to the actual attributes that change, but I've not gotten to > that.) > > I'll update Orca to get the toggle button presentation working again. Great, thanks a lot! Closing this as NOTOURBUG here then. FYI: When I implemented this for NVDA and thought about making use of text attributes instead of toggle button state etc., I ran into the problem that there isn't necessarily any actual text whose text attributes could be used/. Quoting from my commit message in https://github.com/nvaccess/nvda/commit/46a343685247ed7d1adfb737716590ec4be456a0 : "Note: An alternative approach querying the text attributes from the IAccessibleText interface instead of the button state would run into the problem that it works reliably when text is selected, but has no clear way to figure out whether or not bold is enabled or not when there's no selection. (The text attributes need to be queried for a given index, but when the text cursor is e.g. in front of the first character of non-bold text, Ctrl+B would enable bold for newly typed text, but querying the text attributes at index 0 of the existing text would still not report bold, resulting in issues like as observed and described in issue #16412 for MS Word.)"
Actually, the toggle button announcements is a bit of a hack and we'd have to special case certain things. Examples: * Bold/Underline/Italic followed by "on" and "off" make sense. * Left/Right/Center followed by "on" and "off" are less appealing. * Ctrl+D for double underline causes the underline toggle button to be pressed but just saying "Underline on" doesn't give the user the full picture. * Style changes like headings don't have toggle buttons. The real fix is to do what I mentioned before: Present these in response to text-attribute-change events. We get the events already. So it's just a matter of keeping track of what the attributes were so we can do the change-diff. (Sadly the Atspi event tells us that *something* changed; not *what* changed.) Anyway, I filed this bug against Orca and will get to it as soon as I can (working on other things at the moment). https://gitlab.gnome.org/GNOME/orca/-/issues/656
We mid-air-collisioned on the comments. Interesting point about when there's no selection. I'll keep it in mind. But the toggle button solution really isn't great. And, hypothetically, if the toolbars are hidden do they still fire events?
(In reply to Joanmarie Diggs from comment #6) > Interesting point about when there's no selection. I'll keep it in mind. But > the toggle button solution really isn't great. I fully agree, but sadly could not come up with a better idea to reliably detect what to announce otherwise when no text is selected, so went with that approach for NVDA. I'd be more than happy about a better solution. > And, hypothetically, if the > toolbars are hidden do they still fire events? No, they don't in a quick check with gtk3 and disabled toolbars and sidebar. (The sidebar has another "Bold" toggle button.) One might argue that this is in line with what users relying on the visual representation (don't) see when toolbars are disabled. But then, I don't see any reason to not make the information available on purpose if there is a reasonable way to get it a different way. FWIW, if the menu is enabled, there is still this event: 20.5 object:state-changed:checked(1, 0, 0) source: [check menu item | Bold] application: [application | soffice] (The check menu item is presumably the "Format" -> "Text" -> "Bold" one.)
(In reply to Michael Weghorn from comment #7) > One might argue that this is in line with what users relying on the visual > representation (don't) see when toolbars are disabled. But then, I don't see > any reason to not make the information available on purpose if there is a > reasonable way to get it a different way. And of course, for the case where text *is* selected, the visual representation on screen changes regardless of whether or not toolbars are enabled. So at least for that case, using text attributes sounds like a more reliable alternative in any case.