How can I make a custom listbox usable without a mouse?
Quick answer
Use a native <select> if its standard option-selection behavior meets your needs; it provides a labeled form control and built-in browser interaction. If you build a custom listbox, define how keyboard focus moves, how selection changes, and how each state is shown. Support Up and Down Arrow, and consider Home, End, and type-ahead for longer lists. Test the component with a keyboard. [S1] [S2]
The question, the details, the next step.
I have a short list of choices in a form. Is a custom listbox worth building just so it looks more like the rest of the page?
Usually, start by asking whether the choices need behavior that a native control cannot provide. A labeled HTML <select> supports choosing one or multiple options and includes browser-provided interaction. Its exact appearance and keyboard details can differ across browsers and operating systems, so check it in the environments your audience uses. If the standard control fits the task, it avoids making you recreate a widget’s keyboard behavior yourself. [S2]
A custom listbox may be appropriate when the design or interaction genuinely calls for one, but matching its appearance is not enough. A listbox represents options; it is not a container for nested interactive controls such as buttons inside each option. [S1]
If I do make one, what should happen when someone tabs to it and uses the arrow keys?
Write down the interaction before styling the component. In the listbox pattern, focus generally lands on the selected option, or on the first option if nothing is selected. Up and Down Arrow move among options. Home and End are optional, but strongly recommended when there are more than five options; type-ahead is recommended, especially when there are more than seven. [S1]
For example, suppose a single-select list has “Small,” “Medium,” and “Large,” with “Medium” selected. When the user reaches the listbox, make the focused option understandable. Arrow-key movement should be predictable, and the user should be able to tell which option is selected. Decide whether moving focus also changes selection or whether selection stays put until a separate action. The pattern allows either model for single selection, but the component should use one consistently. [S1]
How do I avoid confusing the option that has focus with the option that is selected?
Treat focus and selection as separate states in both your design and your testing. Focus answers, “Where will the next keyboard action go?” Selection answers, “Which choice is currently chosen?” The listbox guidance explicitly distinguishes DOM focus from selected state and allows focus to move among options independently of selection. [S1]
If your single-select design keeps selection unchanged while focus moves, provide clear, distinguishable visual cues for both states. If selection follows focus instead, make the update apparent as the user moves. In either model, check that the focused option remains visible and that users can identify the current choice without relying on color alone. These are implementation recommendations; the pattern establishes the distinction and permitted models, not a required visual design.
What should I test before calling the custom version done, especially if it allows multiple choices?
Test the whole interaction using only the keyboard: reach the control, move through its options, identify focus and selection, and make the intended choice or choices. For a multi-select listbox, choose a selection model and document its keys rather than assuming the single-select behavior applies; the pattern describes separate models and keys for multiple selection. [S1]
A useful test case is a list with no initial selection, one with an initial selection, and—if supported—a list with several selected options. Check that keyboard movement does not make the state ambiguous, and that the form’s chosen values match what the interface communicates. The pattern describes behavior, and native-control behavior can vary by platform; neither establishes that a particular implementation is accessible or works identically everywhere. Test your actual component and target environments. [S1] [S2]
A practical checklist
Use a labeled native
<select>unless a custom listbox has a specific interaction need.Specify where focus goes when the listbox receives keyboard focus.
Implement Up and Down Arrow movement; consider Home and End for lists over five options and type-ahead for longer lists.
Choose and document whether focus movement also changes selection.
Make focused and selected states distinguishable, including when they belong to different options.
For multiple selection, define and test the selection model and its keyboard controls.
Test the real component with a keyboard and in the browsers and operating systems that matter to your audience.
A few more useful answers
Does a listbox have to select an option as soon as focus moves to it?
No. For single selection, the pattern permits selection to follow focus or to remain separate. Pick one behavior and make focus and selection clear to users. [S1]
Are Home, End, and type-ahead required for every listbox?
The guidance describes Home and End as optional but strongly recommended for lists with more than five options, and type-ahead as recommended, especially for lists with more than seven. [S1]
Will a native select behave exactly the same on every device?
No such guarantee is established here. Native controls provide built-in interaction, but keyboard details—particularly for multiselect controls—and appearance can vary by browser and operating system. [S2]
Sources
References used for this guide.
- [S1] W3C WAI-ARIA APG: Listbox Pattern w3.org · Checked
- [S2] MDN: HTML select element developer.mozilla.org · Checked