Comment 12 for bug 1549733

It is not and has never been a “requirement” that “Keyboard focus should follow tap/ click so that pressing (Shift)Tab moves relative to the component last interacted with”. That would be highly unpleasant if it applied, for example, to scrollbars, panel resize handles, or window resize handles. Unfortunately, because the initial toolkit designers were focused on touch input, the toolkit specification did not make a distinction between elements that should be focusable and elements that should not.

So, Femma has just approved my definition of the three focusability classes for elements, and it is now part of the specification template for toolkit elements to define which focusability class it belongs to. She’s also approved my definition of the three selectability classes for lists. Making lists non-pointer-selectable by default would make *this* list non-pointer-selectable, which should mean tapping the list item will not focus its switch, which should mean that Space does not toggle the switch, which fixes this bug.

To summarize: When most of your input is with touch, it would be ugly for most controls to get focus rings — and most list items to look selected — just because you tapped them and *might* use a keyboard to navigate through them later. The toolkit currently tries to solve this by suppressing the focused/selected appearance based on *how* the item was focused/selected. This has turned out to be mistaken because it results in surprising behavior if you *do* use a keyboard later. A better solution is that for many types of control — and items in many lists — tapping/clicking should not focus/select the control in the first place.