How can I show which column is focused or selected in a data grid?
Quick answer
Show focus and selection as separate states: use a clear indicator on the cell or column that receives keyboard input, and a different persistent treatment for selected columns. Don’t rely on color alone; combine it with a border, outline, icon, or label where appropriate. Test the states independently, including when focus moves without changing selection. The exact keyboard behavior depends on the grid control and its selection model.
The question, the details, the next step.
What’s the key distinction I should design for? In my grid, a user can move around with the keyboard and also select columns for an operation.
Treat focus and selection as two different states. Focus identifies the part of the interface that receives keyboard input; selection marks an item to be included in a group operation. Microsoft’s accessibility documentation distinguishes the concepts this way. [S1]
In your grid, a focused cell could be in one column while a different column remains selected. Try a localized outline around the focused cell and a separate, consistent treatment across selected columns, such as a subtle background plus a marker in the header. Keep the focus indicator visible when focus is inside a selected column. These are design suggestions, not a visual specification prescribed by the source.
Should focus be shown on the column header or on the cell? I need users to understand where keyboard navigation will go.
Show focus where keyboard input actually goes. If arrow-key navigation moves the active position between cells, indicate focus on the focused cell. If a separate interaction moves focus among column headers, indicate it on the active header. Avoid showing a whole-column focus treatment when only one cell has focus, unless that reflects how your grid behaves.
Keep the selected-column indicator distinct and stable as focus moves. For example, a selected header might have a checkmark while the focused cell has an outline. Pairing a shape or border with color can help distinguish the states. The sources establish the conceptual distinction, not required colors, shapes, or contrast values.
How can I make sure the distinction works with keyboard navigation, especially when selection does not change as focus moves?
Write down what each key is meant to do in your grid before reviewing the visuals. In the documented Windows ListView and GridView controls, arrow keys can move focus independently of selection in single- and multiple-selection modes; the interaction tables also describe Space and modifier-key effects on selection. [S2] This is an example for those controls, not a rule for every grid.
Review your grid’s own behavior with these cases:
- Move focus to another cell. If selection should stay put, confirm that only the focus indicator moves.
- Select a column and check that its marker appears without obscuring the focused-cell indicator.
- Move focus into and out of a selected column. Confirm both states remain clear when they overlap and when they do not.
- Test any modifier-key selection behavior your grid supports, including multiple selected columns if applicable.
- Repeat using keyboard-only input; don’t infer keyboard behavior from a mouse click.
Use the grid’s intended interaction model rather than copying another control’s key bindings.
Can you give me a short checklist I can use in a design review?
Use this checklist on the interactive grid, not just a static mock-up:
- [ ] Identify what receives focus: a cell, header, or another grid element.
- [ ] Define what column selection means, such as inclusion in an operation.
- [ ] Give focus and selection visibly different treatments.
- [ ] Check that focus stays visible inside a selected column.
- [ ] Move focus without changing selection and confirm both states remain accurate.
- [ ] Exercise the grid’s intended keyboard navigation and selection actions.
- [ ] Check that the states are distinguishable without relying on color alone.
A review note could say: “Focus is shown on [focused cell/header] with [focus treatment]. Selected columns use [selection treatment]. When focus moves, selection [does/does not] change. I checked [keyboard cases] for overlapping and separate states.” Replace the brackets with your grid’s actual behavior; the note is a test plan, not proof that the behavior has been verified.
A practical checklist
Specify whether focus belongs to a cell, header, or another grid element.
Define what column selection means for the relevant operation.
Use different visual treatments for focus and selection.
Verify focus remains visible inside a selected column.
Move focus without changing selection and check that both states stay accurate.
Test the grid’s intended keyboard navigation and selection interactions.
Check that users can distinguish the states without relying on color alone.
A few more useful answers
Can focus and selection be on different columns at the same time?
Yes, if the grid allows focus to move independently of selection. Show the focused position and selected columns separately so users can identify both.
Should I copy the keyboard behavior of a Windows grid control?
Not automatically. The cited Windows documentation describes those controls and their selection modes; it does not establish the right key bindings for every grid.
Is a different background color enough to distinguish the states?
It may not be clear on its own. Consider combining color with a border, outline, icon, or other consistent indicator, then review the result in your interface.
Sources
References used for this guide.
- [S1] Selection and Focus Properties and Methods learn.microsoft.com · Checked
- [S2] List view and grid view learn.microsoft.com · Checked