Bug 71764 - ACCESSIBILITY: new UI widget layout start center incorrect subwindow relationship impacting <TAB> and Cursor movements [a11y]
Summary: ACCESSIBILITY: new UI widget layout start center incorrect subwindow relation...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected) Master
Hardware: Other All
: medium normal
Assignee: Caolán McNamara
Whiteboard: target:4.3.0
Depends on:
Blocks: Start-Center-Accessibility
  Show dependency treegraph
Reported: 2013-11-19 00:52 UTC by V Stuart Foote
Modified: 2016-10-25 19:54 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description V Stuart Foote 2013-11-19 00:52:54 UTC
Split from bug 71628

Using Windows 7 sp1 64-bit with NVDA and JAB active
Build ID: f99736820a23cb7e37139607713658dea1c69dd4
TinderBox: Win-x86@42, Branch:master, Time: 2013-11-18_00:10:12

When positioned into the menu dialogs of the latest StartCenter, there are 4 functional "subwindows": Open-Templates :  Create New XXX (document, spreadsheet, presentation, drawing, formula, database) : Help-Extensions : Thumbnail views (of recent document list).

Correct keyboard navigation would be F6 keys to cycle from subwindow to subwindow including the File-MenuBar.  As implemented F6 keys will only toggle between the File-MenuBar and the Open-Templates subwindow--duplicating the behavior of the F10 reserved key.

Additionally, the <TAB> and <Shift><TAB> moves in a single round through all button objects on all subwindows.  More functional would be for the <TAB> to move between subwindows--duplicating ideal F6 movement--and then Cursor <U,D,L,R> key movements would control movements in each subwindow.

Adjustment of <TAB> and Cursor movements between GTK+ widget UI elements are essential to consistent keyboard navigation and directly to Assistive Technologies that require them.
Comment 1 V Stuart Foote 2013-11-19 15:49:02 UTC
On Fedora 19 64-bit kernel 3.10.11-200.fc19.x86_64
Build ID: f99736820a23cb7e37139607713658dea1c69dd4
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2013-11-17_23:56:22

Verified issues are present on Linux builds of LODev4.2.0alpha1+
Comment 2 Commit Notification 2014-01-16 14:31:02 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":


Related: fdo#71764 allow extensions button to group with help

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
Comment 3 V Stuart Foote 2014-01-16 15:55:19 UTC
(In reply to comment #2)
Cool, but will that impact moving onto, or back from, the thumbnail view?

Would not want to cursor advance from 'Extension' onto thumbnail view. Nor backward cursor from the thumbnail views.  That boundry should be limited to <TAB> positioning or <F6> (if that can be implemented).

Comment 4 Tamás Zolnai 2014-01-16 19:11:14 UTC
I tested it and Caolán's patch allow cursor movements just between the two button. So thanks Caolán! Cursor accessibility is OK.

I disagree with your suggestion to implement <TAB> (and <SHIFT><TAB>) movements on that way. As I see in LO it is a general concept, that <TAB> touches all buttons and not jump between groups of UI elements. If you have problem for this general concept, then open a new bug for it please.
Comment 5 retired 2014-01-17 10:15:04 UTC
I think this is good how it works.

If users want to get to recent used documents, they can shift + tab (to go in the other direction - at least on OSX).

So can we set this to fixed?

I'm unsure what to make to make of V Stuart's suggestion to allow tabbing between the 4 sections and use arrow keys for the navigation in those sections. It might be against standard tab behavior, but would allow for much quicker navigation.

Maybe (but that would be another bug then) it would be smart to open the StartCenter with focus on the recent documents section? I find it hard to decide, which section will see most usage from all users. But I doubt that with the recent file list it will be open file. And even if that is the case you can still cmd + O (open shortcut on OSX) to open another document. So that would be another argument for opening with recent documents in focus.

Any thoughts on how to move this forward? Or do others think this is all set? And StartCenter has reached a rather stable state and is ready for release?
Comment 6 V Stuart Foote 2014-01-22 20:42:16 UTC
On Windows 7 sp1, 64-bit with
Build ID: 77637324abc193d831bb4a0fa6f9a91ef3601960
TinderBox: Win-x86@39, Branch:master, Time: 2014-01-22_16:19:04

The <F10> reserved key is behaving correctly now.  We can move from any active element --to the menu bar-- and back.  The cursor <U,D,L,R> movements are good--active only within the GtkBox they belong, and they are not crossing bounds.

Only issue remaining is handling the <F6> reserved use key.  Currently its only active mapping is between the menu bar and the first GtkBox (holding the Open File and Templates buttons) so it is always landing on the 'Open File' button.

I don't know if adjusting the <F6> landing would require adjusting the GTK packing, or simply changing the XML sequence within the UI config file.  But if we could shift the single <F6> target onto the 'Template View' list of recent documents that might be the best landing target.
Comment 7 V Stuart Foote 2014-02-01 16:08:30 UTC
All issues verified fixed with commit http://cgit.freedesktop.org/libreoffice/core/commit/?id=5b1e68bd852cac4534c5ce2e548187dce1d4561a

On Windows 7 sp1, 64-bit

Build ID: a995462e6855061816c6529c366f20ace2b45868
TinderBox: Win-x86@42, Branch:master, Time: 2014-01-31_23:29:34