“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. ** Changed in: ubuntu-ux Status: In Progress => Fix Committed ** Changed in: ubuntu-system-settings (Ubuntu) Status: Incomplete => Invalid ** Changed in: ubuntu-ui-toolkit (Ubuntu) Status: Confirmed => Triaged ** Description changed: Nexus7, rc-proposed, r373 Ubuntu UI Toolkit version r1795 How to reproduce: 1) Connect bluetooth keyboard 2) Open system settings 3) Open Language & Text view 4) Press tab until the n-th switch shows its focus frame 5) Now tap (using touchscreen) on the m-th list item, with m < n (tap on the list item, not on the switch of that list item) NOTE: It is important that m < n, the bug will not trigger on listitems that have not been focused at least once! 6) At this point the focus frame around the n-th switch has disappeared 7) Now press Space on the keyboard Expected outcome: Nothing, because there is no focus frame anywhere on the screen This is confusing for the user as he can never be sure about which item will be actioned by the keyboard keys Actual outcome: The switch of the m-th list item is triggered, even though that list item or switch were not showing any focus frame + + <https://goo.gl/LCxiWO>: “To avoid errors from unintended focus and + distraction from irrelevant focus rings, there should be three classes + of control: … • Non-pointer-focusable: Focusable only by Tabbing or + other non-pointer input, not by using a pointing device.” + + <https://goo.gl/fscyyx>: “To avoid distraction from irrelevant + selection, there should be three classes of list: … • Non-pointer- + selectable: Any enabled item in the list can be selected using Up or + Down keys, or by other non-pointer input, but not by using a pointing + device … Any list that is non-pointer-selectable should be non-pointer- + focusable.” -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in Ubuntu. https://bugs.launchpad.net/bugs/1549733 Title: SystemSettings Language&Text view: hitting Space on HW keyboard triggers switch even when it (or its list item) does not show any visual focus frame Status in Canonical System Image: Confirmed Status in Ubuntu UX: Fix Committed Status in ubuntu-system-settings package in Ubuntu: Invalid Status in ubuntu-ui-toolkit package in Ubuntu: Triaged Status in ubuntu-ui-toolkit package in Ubuntu RTM: Confirmed Bug description: Nexus7, rc-proposed, r373 Ubuntu UI Toolkit version r1795 How to reproduce: 1) Connect bluetooth keyboard 2) Open system settings 3) Open Language & Text view 4) Press tab until the n-th switch shows its focus frame 5) Now tap (using touchscreen) on the m-th list item, with m < n (tap on the list item, not on the switch of that list item) NOTE: It is important that m < n, the bug will not trigger on listitems that have not been focused at least once! 6) At this point the focus frame around the n-th switch has disappeared 7) Now press Space on the keyboard Expected outcome: Nothing, because there is no focus frame anywhere on the screen This is confusing for the user as he can never be sure about which item will be actioned by the keyboard keys Actual outcome: The switch of the m-th list item is triggered, even though that list item or switch were not showing any focus frame <https://goo.gl/LCxiWO>: “To avoid errors from unintended focus and distraction from irrelevant focus rings, there should be three classes of control: … • Non-pointer-focusable: Focusable only by Tabbing or other non-pointer input, not by using a pointing device.” <https://goo.gl/fscyyx>: “To avoid distraction from irrelevant selection, there should be three classes of list: … • Non-pointer- selectable: Any enabled item in the list can be selected using Up or Down keys, or by other non-pointer input, but not by using a pointing device … Any list that is non-pointer-selectable should be non- pointer-focusable.” To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1549733/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp