I've been learning how users can interact to GNOME using just the keyboard, after reading Peter Vágner email to the (a11y) mailing list. Reading the documentation [2], the main shortcuts for keyboard navigation in applications are:
1) Tab: Moves keyboard focus between different controls. Shift+Tab does the same in the reverse order. 2) Ctrl+Tab: moves between groups of controls and can also break out of a control that uses Tab itself, such as a text area. Shift+Ctrl+Tab does the same in the reverse order. 3) Arrows keys: Move selection between items in a single control, or among a set of related controls. It seems to me there some inconsistencies, or at least the definition of control, group of controls and items are fuzzy in practice. Some cases to explain this: gnome-control-center: What I expect is three groups of controls: find, Personal, Hardware and System. However, the Ctrl+Tab doesn't work as I expected. In this application, Tab behaves as I expected Ctrl+Tab should do. This means that find, Personal, Hardware and System are controls instead of groups and there are only two groups controls: find and everything else. The arrow keys allow me to move between all the the options. Online accounts: This is tricky. The item selected from the list on the left determines the content of the right panel. The current keyboard navigation layout doesn't convey this relationship IMHO. The user starts in the first item of the list, pressing Tab moves the focus to the add button and pressing Tab again moves the focus to the controls on the right related to the item selected on the list. IMHO this behaviour is confusing. To convey this relationship, I guess that pressing Tab should move the focus to the controls related to the item selected on the list. However, this fix is not totally perfect, because the minus button for removing this account (and related of the selected item on the list), it is not the following button focused by pressing Tab, though it can be reached by pressing the left arrow. gnome-calculator: It works ok, except that there aren't any group of controls. I think it makes sense to have the following groups: calculator selector, calculator display and the keys. I like the fact I can navigate the keys with tab or using the arrows keys, but also you can use Ctrl+Tab, and this is not as good IMO. Region and Language: I focus in the language menu here. You can navigate the items of the list using Tab or the arrows keys. I find strange the fact the enter key doesn't work to activate the "more language" option and you have to press the space key instead. The language menu after pressing the "more languages" options is pretty similar to the previos menu. It has much more language-items and a search control. The navigation in the items is pretty similar, using Tabs or arrows keys. It is weird that the scroll of the list don't follow the item selected in the list, so the selected item can be out of view easily. In general terms, I think that the keyboard navigation will benefit of a better definition of control groups. This is something that it has to be done along with the design of the interface, so I think it deserves a section in the HIG and mentioned in other sections. I take as granted that this can be done with the current version of GTK+. I think that the user should be able to reach linearly all the controls shown in the interface by pressing Tab (except when it is necessary to use Ctrl+Tab to break out of a control that uses Tab itself). You can also navigate controls using the arrows, it becomes very handy when the group of controls have grid (or sort-of) layout. And finally, items in lists and similar can me reached by using the arrows, and unless the items can be considered a control itself, Tab shouldn't work here IMO. Another issue I think it deserves some attention is that accelerators are not shown in the menus of in certain redesigned applications like gedit. And, in general, accelerators are not shown in the Application Menus. Also, the use of buttons in the new design usually means as well that accelerators for those options are not shown. In previous/old designs, buttons usually were a way to help mouse oriented users to easy access to frequently used options, and those options were also in the menus with their accelerators. In the new designs, the buttons are usually the only way that those options are shown in the interface. They only way I can think of to show accelerators in buttons is by adding this info in the tooltips, but currently they only shown briefly desc of the action assigned to the button. My opinion is that accelerators must be shown because they really encourage users to learn how to use the applications using only the keyboard. I think it is good idea not to shown accelerators if not keyboard is detected, but, if detected, they must be shown by default. And related to this, GTK+ deprecated the support for changing accelerators since 3.10. This maybe is not a great lost, because it is supposed that most common accelerators are standarised by the HIG [4]. However it could be useful in certain situations, for example, when an option doesn't have any accelerator, adapt applications to other envs or personal needs, etc. I hope this message can help to get some debate and eventually take some actions to improve the situation :-) Cheers, -- Juanjo Marín [1] https://mail.gnome.org/archives/gnome-accessibility-list/2014-October/msg00001.html [2] https://help.gnome.org/users/gnome-help/stable/keyboard-nav.html.en [3] https://git.gnome.org/browse/gtk+/commit/?id=2d79334bb069224966b3dcd8456967c9800e8fd0 [4] https://developer.gnome.org/hig/stable/keyboard-input.html.en _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
