[g-a-devel] Some notes about the status of the keyboard navigation in GNOME 3.14

[Juanjo Marín <juanjomarin96 yahoo es>]

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