soffice: Report keyboard-triggered formatting toggles in Writer

[michaelweghorn]

Link to issue number:

Fixes #4248

Summary of the issue:

When toggling text formatting in LibreOffice Writer using keyboard shortcuts (eg. Ctrl+B for toggling bold when using English UI), NVDA was not reporting whether bold was enabled or not.

Description of user facing changes

In LibreOffice Writer (version 24.8 and newer), when toggling text formatting (bold, italic, underline, subscript/superscript, alignment) using the corresponding keyboard shortcut, NVDA announces the new formatting attribute (e.g. "Bold on", "Bold off"), similar to how it does for Microsoft Word.

Description of development approach

In the SymphonyDocument class, register gestures for keyboard shortcuts that can be used to toggle formatting in LibreOffice Writer.

Add a method to handle the gestures, which is the same for all attributes and enables processing of state change events on toolbar buttons until a timeout (of currently 0.15 seconds) is reached. During that time, when a state change event for a toolbar button is received from LibreOffice, the name of the button and its new state (on/off) are announced.

This also requires a corresponding change in LibreOffice [1] so that the state change events for toolbar buttons are actually sent, contained in LibreOffice >= 24.8:

commit 0425b6eb47830b1fe630dc0128d5049f4b3e5582
Author: Michael Weghorn <[email protected]>
Date:   Tue Apr 16 19:02:30 2024 +0200

    tdf#160695 wina11y: Send status change events for toolbar buttons

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.)

[1] https://git.libreoffice.org/core/commit/0425b6eb47830b1fe630dc0128d5049f4b3e5582

Testing strategy:

1. start NVDA
2. start LibreOffice Writer (current development version, e.g. an upcoming daily build available from [2]).
3. Press Ctrl+B to enable Bold
4. Verify that NVDA announces "Bold on"
5. Press Ctrl+B again to disable bold formatting
6. Verify that NVDA announces "Bold off"
7. Type "hello world"
8. repeat steps 3-6
9. move text cursor to the beginning of the text
10. repeat steps 3-6
11. select the text
12. repeat steps 3-6
13. repeat steps 1-12 for other formatting attributes (Ctrl+I for italic, Ctrl+U for underline,...)

[2] https://dev-builds.libreoffice.org/daily/master/current.html

Known issues with pull request:

None

Code Review Checklist:

• [x] Documentation:
  • Change log entry
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• [x] Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• [x] UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• [x] API is compatible with existing add-ons.
• [x] Security precautions taken.

[CyrilleB79]

I am not a user of LO and will probably not perform tests.

One question though. Are the toolbars or their buttons always present or is this configurable by the user (e.g. show/hide toolbar, remove button, etc.)?

[michaelweghorn]

One question though. Are the toolbars or their buttons always present or is this configurable by the user (e.g. show/hide toolbar, remove button, etc.)?

Both, the user interface and the keyboard shortcuts are highly customizable in LibreOffice, so it's e.g. possible for the user to remove buttons or switch to a different interface altogether. (The Tabbed interface has its own a11y issues at the moment though, otherwise announcement should in my understanding also work with that one as long as the corresponding buttons are shown.)

In the case of removing buttons or hiding toolbars, formatting toggles are no longer announced. At first thought, this seems even somewhat in line with what sighted users experience: If the buttons are hidden, there is no more visual feedback either.

An alternative approach to relying on the buttons I thought of initially was using text attributes, but that cannot reliably detect whether e.g. bold is on/off when there's no text selection, s. PR description.

[CyrilleB79]

In the case of removing buttons or hiding toolbars, formatting toggles are no longer announced. At first thought, this seems even somewhat in line with what sighted users experience: If the buttons are hidden, there is no more visual feedback either.

This makes sense. Just check that NVDA fails gracefully in this case or in the case Libre Office is too old, i.e. nothing reported, but no error in the log; a debugWarning may be suitable though.

An alternative approach to relying on the buttons I thought of initially was using text attributes, but that cannot reliably detect whether e.g. bold is on/off when there's no text selection, s. PR description.

Yes, same for MS Word.

[michaelweghorn]

In the case of removing buttons or hiding toolbars, formatting toggles are no longer announced. At first thought, this seems even somewhat in line with what sighted users experience: If the buttons are hidden, there is no more visual feedback either.

This makes sense. Just check that NVDA fails gracefully in this case or in the case Libre Office is too old, i.e. nothing reported, but no error in the log; a debugWarning may be suitable though.

In that case, no state-changed event is emitted on LO side, so simply "nothing happens" (as the newly added SymphonyButton#event_stateChange doesn't get triggered on NVDA side), which seems fine to me.

[michaelweghorn]

Below are some comments on the code.

Thanks!

Also, did you test with quick key typing? E.g. double press ``control+bor even keepcontrol+b` pressed during two seconds.

I hadn't tested that before, but did now. In both cases, just the last state transition is announced, which seems to be the correct behavior to me.