Selection denotes chosen objects and may coincide with or differ from focus
Aliases: selection state · focus state · active item · keyboard selection
What it is
Selection and focus are independent states. Selection means an object belongs to the current set, scope, or target of a batch command; focus means the next keyboard command lands on an element. In a single-select list they may coincide and resemble one highlight. In multi-select lists, file managers, tables, and editors, focus can move among unselected objects while the selected set persists after focus leaves. This separation prevents treating “where the cursor is” as “everything an action will affect.”
Why it happens
Focus is immediate input routing and usually singular; selection is persistent object state and can be zero, one, or many. Binding them prevents keyboard browsing while holding a batch selection, or makes moving focus accidentally change selection. Leaving them unrelated loses context. Clear hierarchy must show where focus is, what the selected set contains, and what commands read. Inconsistent component rules cause people to transfer the wrong model between contexts.
Studying it
Use tables, trees, and file lists: select several objects, browse by keyboard, extend selection, run a batch command, and return. Measure command-target prediction, accidental deselection, wrong batch action, and recovery. Include mouse click, modified-key range extension, arrow movement, and focus entering/leaving the component. Asking “which will be deleted, and which receives keystrokes?” directly tests the semantic distinction.
Where it stops holding
Not every component needs an independent selection set. Ordinary buttons, single-field input, and controls with only one current value can couple focus and value closely. Components supporting batch, range, staging, or multi-view editing cannot conceal separation in the name of simplicity. Screen-reader and keyboard users especially depend on semantic exposure of the relationship rather than color alone.
Applying it
- Specify whether focus movement changes selection, how extension occurs, and which collection batch commands read; keep rules consistent across inputs.
- Use coexisting cues for focus boundary and selected fill/mark so keyboard landing remains visible after multi-selection.
- Show selection count, scope, or object summary before a command so focus movement is not mistaken for a changed target set.
- Validate “select three, move to a fourth, then delete”: people should predict whether the fourth is affected and browse without losing selection.