Bug 146925 - How to use form controls by keyboard only? Description is missing
Summary: How to use form controls by keyboard only? Description is missing
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Documentation (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: accessibility
Depends on: 146906
Blocks: Form-Controls
  Show dependency treegraph
 
Reported: 2022-01-22 21:16 UTC by Albrecht Müller
Modified: 2025-11-25 15:32 UTC (History)
6 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 Albrecht Müller 2022-01-22 21:16:15 UTC
The page https://help.libreoffice.org/7.2/en-US/text/shared/guide/keyboard.html?DbPAR=SHARED describes how to control LibreOffice using only the keyboard.

I did not find any description that explains how to control form controls by keyboard. Here are some remarks about the missing content:

LibreOffice documents (text, spreadsheet, maybe others) may contain control elements such as buttons, checkboxes etc. The author of the document may associate shortcut keys with these controls which are also associated with user interface functions. To resolve the resulting conflicts LibreOffice uses a two state focus system:

a) The focus is in the document. If not defined otherwise this is the default state. This state is accessible via the shortcut Ctrl+F6. The shortcut keys go to the LibreOffice user interface. Shortcuts defined for controls in the document are disabled. No control has a decoration indicating that it has the focus.

b) The focus is on the controls. In this state the shortcut keys defined for the controls in the document are active. There is one control with a visual marker that indicates that this control has the focus. There are a couple of keys (e.g. cursor keys) that allow to move the focus between different controls. The blank key triggers the execution of the action associated with the control that has the focus.

It should be possible reach state b) by pressing Ctrl+F5. This does not work due to a conflict in the user interface: Ctrl+F5 is also defined to toggle the sidebar. Thus the description should take into account how bug 146906 is resolved.
Comment 1 Michael Weghorn 2024-10-29 12:32:23 UTC
(In reply to Albrecht Müller from comment #0)
> It should be possible reach state b) by pressing Ctrl+F5. This does not work
> due to a conflict in the user interface: Ctrl+F5 is also defined to toggle
> the sidebar. Thus the description should take into account how bug 146906 is
> resolved.

I'm not very familiar with these, but there seems to be a general difference between design mode being on or off. When design mode is on, form controls seems to be considered as the kind of objects that get focus using Shift+F4.

> It should be possible reach state b) by pressing Ctrl+F5. This does not work due to a conflict in the user interface: Ctrl+F5 is also defined to toggle the sidebar. Thus the description should take into account how bug 146906 is resolved.

For non-design mode, the Ctrl+F5 shortcut for moving toggling between form controls and document appears to have been removed in the context of tdf#146906.


If I manually assign a shortcut, e.g. Ctrl+F to "Control Focus", I can use that shortcut to move focus to a form control (but not back, so it's not toggling, just moving focus to a control), not sure whether that's the same one. Heiko might be able to say more.

Can you please clarify what exactly this documentation bug report is about? Should it document that it's possible to manually assign a shortcut or is it rather meant as a "document the solution to be found in bug 146906", in which case it would be blocked until that one is resolved?


Just to mention it, enabling "Form" -> "Automatic Control Focus" in the menu, saving the file and reopening results in the first form control receiving focus automatically.


Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 4692b33314669515a973f69cddd27b688327ca99
CPU threads: 32; OS: Linux 6.11; UI render: default; VCL: gtk3
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: CL threaded
Comment 2 Adriani90 2024-11-29 13:25:47 UTC
@Michael Weghorn I think it would be nice to find a document solution entirely without having to assign shorcut keys.

1. Form fields and form elements should be focusable with arrow keys both when form design mode is on or off.
* In case of text fields, writing something while the text field is focused  should directly go into the field without having to press something to open the field.
* In case of combo boxes, spin buttons and other data containers which can be expanded or colapsed, pressing alt+down arrow should open them, and then arrow keys should allow for choosing an item. Pressing enter should activate the item, pressing escape should close the combo box / spin button.
* In case of radio buttons or checkboxes, space bar should enable or disable them.

This is how form controls work in web documents, in MS Office and all other programs I know of which provide accessible form fields.
Comment 3 Michael Weghorn 2024-12-06 09:26:50 UTC
@Adriani90: Thanks for the valuable input. That sounds reasonable, and also looking at how it's implemented elsewhere definitely makes sense.

(In reply to Adriani90 from comment #2)
> 1. Form fields and form elements should be focusable with arrow keys both
> when form design mode is on or off.

If that refers to using the arrow keys to navigate through the document, handling might have to take into account where a form control is anchored (to paragraph, to character, as character).
Comment 4 QA Administrators 2025-06-05 03:11:20 UTC Comment hidden (obsolete)
Comment 5 QA Administrators 2025-11-25 15:32:50 UTC
Dear Albrecht Müller,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp