Lists: Also cover input (keyboard) focus in design patterns doc
One aspect of list behavior that list-design-patterns currently doesn't touch on is keyboard focus. I think it would be helpful to provide some standards for implementing keyboard focus in a well-organized and predictable manner. In particular, detailing what widgets should accept focus, and in what order, so that focus is predictable and the interface isn't cluttered with redundant/useless focus points.
Redundant/Superfluous focus points
For example, in gnome-control-center 3.30.3, the 'Notifications' pane (which, as I note in GNOME/gnome-control-center#361 (closed), contains two list entries at the top which can't be row-toggled) does allow both of those individual rows to be keyboard-focused, separate from and in addition to their embedded switches.
So even though there's nothing that the rows themselves will accept for input, and no reason to ever place input focus on them, the user is still forced to hit Tab twice when navigating from the first row's switch to the second via the tab ordering, because it's necessary to skip over the uselessly-focused second row in between.
When rows and their embedded controls are tied together (so that clicking the row background activates the control), IMHO they should just share a single keyboard focus between them — whether it's only the row, or only the control, I don't really have an opinion, but picking either and making it standard would be better than leaving that up to individual developers' whims.
When rows are inert and can't be interacted with in any useful way, they shouldn't accept keyboard focus at all. Focus should jump directly to the embedded control that is activatable.
And having those things explicitly spelled out in the UX standard would go a long way towards ensuring consistency, I think.
Focus order / non-keyboard-navigable interfaces
On the other hand, keyboard focus is completely broken in gnome-control-center 3.30.3's 'Universal Access' pane (ironically), making it effectively un-navigable by keyboard. The problems:
- There's no tab order at all. Trying to switch between controls with the Tab key is useless, nothing is connected together.
- Clicking one of the list rows will place keyboard focus on the list, allowing focus to be moved between items using the ↑ and ↓ arrow keys, but focus is confined to the row backgrounds (embedded controls on the rows still can't be reached).
- Since many of the list rows don't react to row-level activation, being able to focus them is useless.
- Tab remains useless even when the list is focused. Tabbing off any list row warps the focus to... nowhere, apparently.
Having keyboard focus covered in the standard design patterns docs would hopefully help to prevent such problems, by making it a conscious aspect of UI development and testing.