Bug 113488 - Better support for Assistive Technology tools by exposing descriptive tooltips text with keyboard navigation
Summary: Better support for Assistive Technology tools by exposing descriptive tooltip...
Status: NEEDINFO
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: accessibility
Depends on:
Blocks: Main-Menu Context-Menu a11y, Accessibility Toolbars-Tooltips Toolbars-Labels Tooltip
  Show dependency treegraph
 
Reported: 2017-10-27 22:23 UTC by V Stuart Foote
Modified: 2022-07-01 14:59 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description V Stuart Foote 2017-10-27 22:23:02 UTC
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.
Comment 1 Michael Weghorn 2022-07-01 14:05:31 UTC
(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)?
Comment 2 Michael Weghorn 2022-07-01 14:59:23 UTC
(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.)