Comment 9 for bug 1549733

“For controls, focus refers to which control has first claim on any non-pointing input, such as input from a keyboard…” <https://goo.gl/oZlhEU> (currently Canonical-only link, sorry). That is the only reason for focus to exist, so there should not be any difference between “focused” and “I accept keyboard input”. (Text fields used to, as Christian says, change background color distinct from their focus ring. It’s good that they no longer do, because it made unfocused fields look disabled. So now they should have a focus ring instead … but that’s a separate problem.)

Apart from that, I think any of three changes to the reported behavior would make it unsurprising. But each would have other consequences:

A. Give the switch a focus ring. But this would be too distracting, because — especially on a phone — you hardly ever toggle controls with a hardware keyboard. Furthermore, as “5) … tap on the list item, not on the switch” implies, the switch isn’t (or shouldn’t be) focused anyway. Space is toggling the switch not because it is focused, but because it is the only control inside the selected list item. (Lists of checkbox items should behave the same way: select with arrow keys, Space to toggle.)

B. So, make the selected list item look selected then! But this would be distracting too, because this screen isn’t really a “list” of anything in the non-technical sense; on many other platforms it wouldn’t be using a list control at all. So there’s a larger question about whether System Settings should be using a list control on screens like this. But even in the “Keyboard Layouts” or “Wi-Fi” screens, which do have genuine lists of things, once you tap any of the items it still shouldn’t be visibly selected, because which one you happened to tap on most recently is either not interesting or indicated in some other way. So, this isn’t a System Settings bug.

C. Make tapping not select the list item at all, so Space doesn’t do anything inside the item. Selection inside a list has similarities with focus outside a list (which is one of the reasons people often confuse the two). One similarity is that sometimes it’s appropriate only when you’re actively using an external keyboard. A focus example: If you have a password field focused, you should be able to Tab to the “Show password” checkbox, but for tapping the checkbox to focus it would be annoying, because it would unfocus the password field. So text fields should take focus on tap or Tab, but checkboxes should take focus *only* on Tab. Similarly with list selections: sometimes a list always has exactly one item selected at a time, and in that case selection should always be visible, but in other cases selection is interesting *only* if you’re using a keyboard to navigate through it.

Unfortunately, neither of these subtleties have been specified yet. The focus subtlety should have been part of the recent “focus states” design project, but that project got sidetracked. No-one has yet specified the behavior of lists, as opposed to list items. And the spec for list items uses the word “select” only to refer to activation, not selection.

So, I’ve proposed a change to “General behavior for all controls” to define three classes of control, with examples of each: pointer-focusable, non-pointer-focusable, and unfocusable. <https://goo.gl/LCxiWO> (Canonical-only link, sorry) Basically, this removes the “thus” from Christian’s statement above, “any (Abstract)Button can be clicked, thus have activeFocus”. For example, click-to-focus should be true for text fields (pointer-focusable), but not for normal buttons (non-pointer-focusable) or scrollbar buttons (unfocusable). Eventually the spec for each type of control should say which of the three focus behaviors it has. Most control types will only ever have one behavior … except for lists, because of the variety of ways they’re used.

So, I’ve then defined three analogous classes of list: pointer-selectable, non-pointer-selectable, and unselectable. <https://goo.gl/fscyyx> (Canonical-only link, sorry) All the lists in System Settings currently should be non-pointer-selectable, which suggests that that should be the default. Therefore, tapping an item in the “Language & Text” screen should not select it. And therefore, pressing Space afterwards should not activate the switch in that item.