By default mouseover events expose a more descriptive tooltip, or an extended tooltip--when offline local help is installed and has an article pointing at the button. And with Assistive Technology (AT) support enabled, on mouseover of a button control the descriptive tooltip is sounded by AT instead of the button label. When keyboard navigation is used: e.g. F10, F6, TAB/ShiftTab, or cursor UP/DOWN/LEFT/RIGHT--the AT sounds *only* the abbreviated button label. Same for menu label, and context menu label which also sound just the short label. If possible, for better accessibility support, keyboard navigation should offer the same audible/visual rendering of the more descriptive tooltip(s) provided with mouseover event of buttons. A rework of label structure for menus, context menus and toolbar button labels is being looked at for bug 108458. Perhaps in conjunction with that, some structural change to facilitate use of tooltip/extended tooltips with keyboard navigation might be implemented.
(In reply to V Stuart Foote from comment #0) > A rework of label structure for menus, context menus and toolbar button > labels is being looked at for bug 108458. Perhaps in conjunction with that, > some structural change to facilitate use of tooltip/extended tooltips with > keyboard navigation might be implemented. I came across tdf#108458 in the context of https://gerrit.libreoffice.org/c/core/+/136722 (v1), which then brought me here again. I don't really understand what the exact intention/request here is: Is it to have the tooltips read out by default by screen readers when focusing an item using the keyboard, e.g. by having them in the accessible name (or accessible description)? If so: At least Orca and NVDA have an option in their settings to announce tooltips also, so I'm wondering whether it shouldn't be dependent on that option whether or not tooltips are announced. Since, IIUC, tooltips can contain rather long help texts, I tend to think that not all users would want to have them announced every time (in particular when experienced with the functionality currently being used), but a short label might be enough then? (And it would hopefully be possible to press some keyboard shortcut to have the screen reader announce the tooltip on demand, but I don't know whether that's currently implemented in the screen readers. Or is it, but LO doesn't provide the information when the UI element has been accessed using the keyboard, as opposed to when mouse-hovering over them?) @Stuart: Could you possibly clarify a bit further what the request in this ticket is (maybe also giving an example scenario of how that would be used)?
(In reply to Michael Weghorn from comment #1) > Is it to have the tooltips read out by default by screen readers when > focusing an item using the keyboard, e.g. by having them in the accessible > name (or accessible description)? > > If so: At least Orca and NVDA have an option in their settings to announce > tooltips also, so I'm wondering whether it shouldn't be dependent on that > option whether or not tooltips are announced. After having looked closer at this option in Orca: I probably misunderstood what the option is about. I thought that would somehow also have an effect when moving keyboard focus to a UI element, but it seems to be mostly about tooltips actually shown on screen, e.g. when hovering using the mouse. (And the "Present tooltips" options is actually in a "Mouse" section in Orca settings.)
Dear V Stuart Foote, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Spent some time with this again, with NVDA 2021.2 on Win 10 and Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b9e3e20bfd102880d12384892eaeca094c38a519 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded with its corresponding Offline/Local help en-US help pack installed. And also Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 98f0dd5e15733ac7f1d929d06ab230b5f04121d5 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded but without its offline/local help installed. With the NVDA screen reader enabled we correctly detect the Assistive Technology (AT) support demand--and the Tools -> Options -> General -> Help 'Extended Tips' responds as activated, as if it had been checked enabled. However, there no longer is a distinction between descriptions drawn from offline help and what is compiled/translated in core. The <F1> links are present and respond with the HTML local or on-line help--but no longer provide the extended tips as with the old Help system. I think we can close this out, as the 'Extended tips' are being delivered for keyboard navigation when AT is signaled active. And not clear the framework of the Help2 can still draw from the help pack content beyond the <F1> linkages.