Download it now!
Bug 98968 - Ghost toolbar in a11y support
Summary: Ghost toolbar in a11y support
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.0.0.5 release
Hardware: All All
: low normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: accessibility
Depends on:
Blocks:
 
Reported: 2016-03-29 20:05 UTC by Jean-Philippe MENGUAL
Modified: 2020-05-23 10:49 UTC (History)
3 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 Jean-Philippe MENGUAL 2016-03-29 20:05:45 UTC
1. Open Writer
2. Press f6
3. Browse the toolbar with f6. After the standard buttons one, the focus goes on a toolbar. It is blank, nothing appears.
4. Go on, it works
5. Go back: shift-f6. Now the ghost toolbar is skipped. Fine.

Regards,
Comment 1 Arnaud Versini 2016-03-29 20:11:55 UTC
Confirmed on LibreOffice 5.1.1 on openSUSE Tumbleweed.
Comment 2 Arnaud Versini 2016-03-29 20:22:48 UTC
Confirmed also by Jean-Philippe on Windows with nvda
Comment 3 Joel Madero 2016-03-29 20:32:22 UTC
Not going to affect high quality work. Lowering to trivial.
Comment 4 V Stuart Foote 2016-03-30 01:43:54 UTC
Actually navigation for Assistive Technology is highly dependent on the F6, F10 and assignment of consistent (predictable) keyboard accelerators and Shortcuts.

This xtra "Ghost Toolbar" (Orca) or empty "Option Pane" (NVDA) is annoying and confusing to folks dependent on Assistive Technology.


F6 (Shift-F6) movement through default Controls on Writer are

   Main menu (File)

   Standard Toolbar

   "Option pane" -- the "Ghost toolbar" of this issue --

   Formatting Toolbar

   Split Pane -- the Sidebar deck --

   Document canvas

   Main menu (File)

F10 toggles between the Main menu and the Document canvas.

This blank "option pane" has present for quite a while, and I've never been able to figure out what piece of the GUI is receiving the focus.

Regardless, it is an annoyance and definitely degrades the UX for those dependent on AT, it should be resolved as reliable navigation is of paramount concern in our accessibility support.
Comment 5 Joel Madero 2016-03-30 01:51:49 UTC
I suggest QA address the flowchart and continue polishing guidance for severity/priority. I was convinced that this is "minor" by Arnaud - to call it normal I think is inconsistent with prior practice.

Minor: Can slow down but will not prevent high quality work;
Normal: Will entirely prevent high quality/professional quality work

If the idea is to make exceptions for accessibility, I think someone should update the flowchart to reflect this. It needs to be updated anyways to remove blocker and MAB


Just my two cents :)
Comment 6 QA Administrators 2017-05-22 13:18:44 UTC Comment hidden (obsolete)
Comment 7 V Stuart Foote 2017-05-22 14:14:45 UTC
Still an issue...
Version: 5.3.3.2 (x64)
Build ID: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; 
Locale: en-US (en_US); Calc: group
Comment 8 QA Administrators 2018-05-23 02:37:59 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2020-05-23 03:44:04 UTC Comment hidden (obsolete)
Comment 10 Arnaud Versini 2020-05-23 10:49:01 UTC
I will check this one later this week