[Libreoffice-bugs] [Bug 140762] No text spoken by screen reader for "Borders" dropdown button items in Calc's formatting toolbar (NVDA on Windows)

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=140762

--- Comment #6 from Michael Weghorn <m.weghorn at posteo.de> ---
With the above 3 commits, the descriptive texts are set for the items in the
"Borders" and "Border Type" dropdown buttons in Calc's formatting toolbar.

Those are shown as tooltips when hovering using the mouse on both, Linux
(tested with kf5 and gtk3) and Windows.

The Orca screen reader on Linux with the gtk3 VCL plugin speaks those texts
when navigating between the items using the arrow keys (left, right, up, down).
(It doesn't say the value of the initially selected entry when pressing space
or Enter, though.)

For Windows with NVDA, texts are not spoken when navigating using the arrow
keys at first. They are spoken when hovering over the items using the mouse.
And after doing so, the item text is also announced by NVDA when using the
arrow keys, so it seems some initial activation/focus is missing. (?)


(In reply to V Stuart Foote from comment #2)
> Have the general case of bug 113488 to expose the descriptive text when
> 'accessible events' are focus triggered, but then individual GUI widgets can
> require some refactoring to expose their controls meaningfully to AT, as
> here.
> 
> Tackle the 'accessible event' firing via keyboard navigation, so movement
> sequences and focus states for the elements in the widget(s).

Thanks for that info! Looking at bug 113488:

(In reply to V Stuart Foote from bug 113488 comment #0)
> 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.

That sounds like it *could* explain the behavior here is well, but...

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

... for the specific case of "Borders" and "Border style" toolbar items (with
NVDA on Windows), it seems that the up/down/left/right keys does lead to AT
announcing the same as the tooltip shows, but only after some "initial
activation" by hovering over one of the items so it's tooltip is shown once, s.
above. Maybe initial focus needs to be handled differently or somesuch. This
might need further investigation.

Any quick ideas?

The above are just my first thoughts on this. I've just started trying to get a
bit familiar with AT. Will try to take a closer look at the bugs you've
mentioned at some point to at least get a deeper understanding.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210304/0d0d0373/attachment.htm>