Some notes about the status of the keyboard navigation in GNOME 3.14
Juanjo Marín <juanjomarin96 <at> yahoo.es>
2014-11-30 22:23:51 GMT
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 , 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
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 . 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
I hope this message can help to get some debate and eventually take some actions to improve the situation
-- Juanjo Marín
gnome-accessibility-devel mailing list
gnome-accessibility-devel <at> gnome.org