> 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
Text fields show a caret whenever they accept keyboard (or OSK) input -
they do show a focus ring only when focused via keyboard.
> A. Give the switch a focus ring
Focus ring on tap would mean changing what focus ring means.
> B. So, make the selected list item look selected then [...]
Selected item? Maybe. How about selected switch?
> C. Make tapping not select the list item [...]
Keyboard focus should follow tap/ click so that pressing (Shift)Tab moves
relative to the component last interacted with - that's a requirement right now.
Conceivably the behavior could be changed to 'anything that won't visually show
keyboard input takes no focus on tap' provided all components including other
types of buttons are re-visited and the keyboard navigation requirement above
is re-visited.
This goes back to my point, we have no requirement to show that input is
accepted, except for text input as a special-case.
** Changed in: ubuntu-ux
Status: Fix Committed => In Progress
--
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:
In Progress
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
