According to LibreOffice Help, Ctrl-Shift-Pgdn should move focus to a foonote. However, at least under GNOME 45, this keyboard operation does not function as documented. For screen reader users and keyboard-only users, there should be a keyboard shortcut bound to an operation that moves focus into the footnote area and which allows notes to be read/edited. Returning to the footnote mark in the main text is also important from a user's perspective. This is an accessibility issue.
Confirmed. Believe the command you'd want is .uno:JumpToFootnoteOrAnchor No command assignment is made to that short cut in Writer module and the global zoom commands assert. Trivial to assign from the customize dialog where it is titled "To Footnote Anchor" Assigned to keyboard shortcut it will toggle between the anchor on document canvas and the footnote or endnote area. The <Ctrl>+<Shift>+<PgDn | PgUp> were assigned globally to "Zoom out" and "Zoom in" respectively for see also bug 45705 [1] and the previous .uno:JumpToFootnoteArea (has slightly different behavior in that it does not toggle between document text and the footnote) was removed--that needs adjustment in the help. Setting as a Documentation issue. But probably should find a slot for the shortcut as it does improve assistive technology and keyboard usage.
(In reply to V Stuart Foote from comment #1) =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/150212
The essence of this bug is that users shouldn't have to edit key bindings to obtain this functionality - there should be a default keyboard assignment. Having the function available but unassigned probably doesn't satisfy accessibility standards/regulations for keyboard operation either (e.g., public procurement standards that inherit WCAG 2.0, criterion 2.1.1).
(In reply to Jason White from comment #3) > The essence of this bug is that users shouldn't have to edit key bindings to > obtain this functionality - there should be a default keyboard assignment. Why? Reallocation of Ctrl + Shift + PgDn for the global Zoom-out / Zoom-in pair was dev choice, under UX advisement. The shortcut assignment was removed, UNO function remains for customization, users can choose a shortcut of their liking. See: https://help.libreoffice.org/latest/en-US/text/shared/01/06140200.html?DbPAR=SHARED#bm_id2322763 > Having the function available but unassigned probably doesn't satisfy > accessibility standards/regulations for keyboard operation either (e.g., > public procurement standards that inherit WCAG 2.0, criterion 2.1.1). Sorry, not going down that rabbit hole. This is a simple documentation issue. There are hundreds of potential UNO actions (across the UI) that could be preassigned to fixed shortcuts, many of them of great potential benefit for keyboard navigation and often assistive technology tool support. Assigning a shortcut for either .uno:JumpToFootnoteArea (with change in documentation) or reassigning one to .uno:JumpToFootnoteOrAnchor is probably now a reasonable improvement to do (movement into the footnote area previously had a shortcut, so folks expect it) but that is not the main issue of a now incorrectly documented shortcut action.
I take the view that components of the UI that cannot be accessed via a keyboard by default need to be made keyboard-accessible, either through a menu option or a key mapping. This is generally how keyboard operability accessibility requirements are understood and interpreted, and justifiably so.
(In reply to Jason White from comment #5) > I take the view that components of the UI that cannot be accessed via a > keyboard by default need to be made keyboard-accessible, either through a > menu option or a key mapping. This is generally how keyboard operability > accessibility requirements are understood and interpreted, and justifiably > so. Yes, and I do verify that from 7.6.0 onward there is no keyboard only navigation down into the footnote area currently mapped, and requiring customization. So a usability issue with a11y impact. Should probably map a new keyboard shortcut, and kind of seems like a contextual menu entry somewhere would be of use. The SB Navigator deck handling of the Footnote objects 'Go to' action only moves focus to the anchor on the document canvas, not to the associated footnote. But immediate issue here remains one of correcting documentation of the reassigned shortcut.
(In reply to V Stuart Foote from comment #6) > () > But immediate issue here remains one of correcting documentation of the > reassigned shortcut. In summary, command .uno:JumpToFootnoteOrAnchor (Module Writer, UI string is "To Footnote Anchor" ) is - not assigned to a keyboard shortcut in Writer at factory settings - not available in any Writer menu or toolbar - no Help page of it own or as entry in any Help page. Has this command been used any time in history? Before documenting it in Help I think the command should be exposed in the UI or a keyboard shortcut assigned as indicated in comment#1.
(In reply to Olivier Hallot from comment #7) Partly, but the current incorrect documentation applys to usage of the .uno:JumpToFootnoteArea whose shortcut had been reassigned. So documentation in URL as listed above [1] needs attention. However, my suggestion was that the alternative control .uno:JumpToFootnoteOrAnchor which functions as a toggle focus between the anchor and the footnote would provide a better UX than the prior JumptoFootnoteArea and its associated <PgUp> to return to the the anchor in canvas. Either control is fine. Just that the <Ctrl>+<Shift>+<PgDn> is no longer assigned and probably should not be reused as the global Zoom controls are relatively more significant. A different shortcut is needed for entering the footnote area, so the toggle JumpToFootNoteArea control makes more sense to assign and document in help. =-ref-= [1] https://help.libreoffice.org/latest/en-US/text/swriter/guide/footnote_usage.html?DbPAR=WRITER#bm_id3145819
(In reply to V Stuart Foote from comment #8) > so the toggle JumpToFootNoteArea control makes more sense to s/toggle JumpToFootNoteArea/toggle JumpToFootnoteOrAnchor/
I struggle with the workflow. Clicking a specific footnote is challenging enough but to get some shortcut working might be even harder. I like Stuart's idea to toggle between the footnote _area_ and the document with "To Footnote Area". But I see not reason for shift+ctrl+PgUp/Down; since shift+ctrl+F is used for repeat search we may use shift+ctrl+N.
Nope, <Ctrl>+<Shift>+N is assigned LibreOffice global for the "Templates..." manager as .uno:NewDoc; don't think we want that overridden for Writer. @Heiko, would you go ahead and pick an *unused* shortcut and assign the .uno:JumpToFootnoteOrAnchor toggle. Then Olivier and team can adjust the documentation against the replacement shortcut. And we might see if Jim thinks a SB context menu placement for jumping to the footnote area makes sense.
(In reply to V Stuart Foote from comment #11) > pick an *unused* shortcut -1 to randomly assign a shortcut
Well not really random, but a shortcut needs to be assigned. As otherwise there is no assigned means to enter the footnote/endnote area (one of the Jump to controls) an a11y issue bcz areas within the document can not be reached with AT, i.e. via keyboard only movements. Using mouse point-n-click is not enough. And expecting *all* users to identify an appropriate control to assign to a shortcut is not viable UX in this instance. Better that we pick one, and document in the help.
The problem is clear and accepted. You rejected my proposal (for good reason) and should come up with something better. And something with up or down makes no sense to me when the action is kinda toggle.
(In reply to Heiko Tietze from comment #14) > The problem is clear and accepted. You rejected my proposal (for good > reason) and should come up with something better. And something with up or > down makes no sense to me when the action is kinda toggle. OK, so think that <Ctrl>+<Shift>+E (for Endnote or Footnote) may work well, it is an unassigned global and is also available in Writer that I see. Also, the single key toggle action of .uno:JumpToFootnoteOrAnchor seems more functional UI than the prior .uno:JumpToFootnoteArea, which requires a <PgUp> to return back to the anchor in the document. Suggest we go with the toggle and tweak the Help article.
https://gerrit.libreoffice.org/c/core/+/164001
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6158928209bd0f6bd532df9092f3a81ff615cdcc Resolves tdf#159863 - Default shortcut to access foot-/endnote area It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I commented on Gerrit: I think this has to be changed, look at what it says at the top of Accelerators.xcu: <!-- problematic combinations Ctrl+Shift+u aka U_SHIFT_MOD1 under GTK/IBUS is for unicode key input Ctrl+Shift+e aka E_SHIFT_MOD1 under GTK/IBUS is for some emoji thing -->
(In reply to Buovjaga from comment #18) > Ctrl+Shift+u aka U_SHIFT_MOD1 under GTK/IBUS is for unicode key input I can confirm this is current for Ubuntu 22.04 + GNOME 42.9. It works in Writer 7.6 to input a Unicode glyph and it would definitely be a shame to lose it. > Ctrl+Shift+e aka E_SHIFT_MOD1 under GTK/IBUS is for some emoji thing That was added by Caolán for bug 116098 back in 2018. Seems there's a bit of automatic shortcut picking depending on DE, see for example https://fedoraproject.org/wiki/Changes/IBus_Unicode_Typing#Detailed_Description But recently I've seen Ctrl + Shift + ;/. being used under GNOME currently, see bug 160474. And IBus have replaced the old default Ctrl + Shift + E with Ctrl + . back in 2021: https://github.com/ibus/ibus/commit/b952d30a1b7c741052c168fe1081ecb4d4b1c034
(In reply to Stéphane Guillou (stragu) from comment #19) > And IBus have replaced the old default Ctrl + Shift + E with > Ctrl + . back in 2021: > https://github.com/ibus/ibus/commit/b952d30a1b7c741052c168fe1081ecb4d4b1c034 Actually, Super shortcuts are used since IBus 1.5.30: https://github.com/ibus/ibus/commit/1520c39d0d6036da725fcecd932883be3f3d3575
(In reply to Stéphane Guillou (stragu) from comment #19) > (In reply to Buovjaga from comment #18) > > Ctrl+Shift+u aka U_SHIFT_MOD1 under GTK/IBUS is for unicode key input > I can confirm this is current for Ubuntu 22.04 + GNOME 42.9. It works in > Writer 7.6 to input a Unicode glyph and it would definitely be a shame to > lose it. > > > Ctrl+Shift+e aka E_SHIFT_MOD1 under GTK/IBUS is for some emoji thing > That was added by Caolán for bug 116098 back in 2018. > Seems there's a bit of automatic shortcut picking depending on DE, see for > example > https://fedoraproject.org/wiki/Changes/ > IBus_Unicode_Typing#Detailed_Description > > But recently I've seen Ctrl + Shift + ;/. being used under GNOME currently, > see bug 160474. And IBus have replaced the old default Ctrl + Shift + E with > Ctrl + . back in 2021: > https://github.com/ibus/ibus/commit/b952d30a1b7c741052c168fe1081ecb4d4b1c034 Thanks, I should have checked it, I was wondering if it's still valid. I can remove the outdated comment. I'm wondering about Ctrl+Shift+u, though, as it is used for .uno:Underline since forever.
(In reply to Buovjaga from comment #21) > I'm wondering about Ctrl+Shift+u, though, as it > is used for .uno:Underline since forever. Ctrl + U, no?
How about ctrl+alt+end? Trying to keep it close to similar commands. It's used on some RDP tools apparently to emulate/bypass ctrl+alt+del. And for shutdown on Mint. Guess we cannot make everyone happy.
(In reply to Heiko Tietze from comment #23) > How about ctrl+alt+end? Trying to keep it close to similar commands. > > It's used on some RDP tools apparently to emulate/bypass ctrl+alt+del. And > for shutdown on Mint. Guess we cannot make everyone happy. See Stéphane's comments, I commented too quickly. Nothing to be done here. (In reply to Stéphane Guillou (stragu) from comment #22) > (In reply to Buovjaga from comment #21) > > I'm wondering about Ctrl+Shift+u, though, as it > > is used for .uno:Underline since forever. > Ctrl + U, no? See https://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/Office/Accelerators.xcu?r=61589282#1449 and other entries for U_SHIFT_MOD1