In a design system, when should a payroll form's pay-frequency field stay a native select, and when is a custom listbox worth building?
answer
- what the platform gives free
- short, plain, single choice
- rich options or filtering
- the contract you inherit
- type-ahead past seven options
basics
~20 sKeep a native select for a short, plain-text, single choice: it brings the platform's picker, keyboard, screen-reader and zoom support for free. Build a custom listbox only when options need rich content, filtering or real multi-select, and budget its whole accessibility contract.
solid answer
~50 sA **native select** is the platform's own single-choice picker. For pay frequency, four plain-text options such as weekly, fortnightly, twice monthly and monthly, it is the right default: it opens the platform's familiar picker on phones, supports the keyboard and type-ahead, exposes name and value to assistive technology, respects zoom and text-size settings, and costs the team nothing to maintain. Its limits are presentation and power: how far its open list can be styled varies by platform, options are plain text, it cannot filter, and native multi-select is awkward. A **custom listbox** earns its cost when options need rich content, such as a photo, name and role, or when filtering or chips are required. Building one means owning the Authoring Practices contract: arrow keys, Home and End, type-ahead, correct name, value and selection states, popup positioning, touch, zoom and screen-reader testing on every platform.
go deeper
Know that a native select is the default for short, plain-text single choices, and name the things it gives you for free.
Explain the trade-off table and the specific requirements, rich options, filtering, multi-select, that justify a custom listbox and what its keyboard contract includes.
Judge a team's request for a custom picker, estimate what it will cost to build and keep accessible, and steer plain cases back to the native control.
Set the system's policy: native first, one blessed custom listbox or combobox for the rest, and documentation that stops each team building its own.
## Two ways to pick one option from a list A **select** lets a person choose one value from a fixed list shown in a compact, collapsible control. A design system can ship it two ways: wrap the platform's **native select**, or build a **custom listbox**, a list of options drawn and scripted by the team, usually inside a popup. | Concern | Native select | Custom listbox | |---|---|---| | Mobile presentation | The platform's own picker, familiar to users | Whatever the team builds, often a popup that fights small screens | | Keyboard and type-ahead | Built in | Must be implemented to the Authoring Practices contract | | Screen-reader name and value | Built in | Must be exposed correctly and tested | | Zoom and text-size settings | Respected by the platform | Must be designed and tested | | Styling the closed control | Usually possible | Full control | | Styling the open list | Limited, and varies by platform | Full control | | Rich option content | Plain text only | Anything, within listbox limits | | Filtering, chips, multi-select | Not available, or awkward | Possible | | Maintenance | The platform's job | The system team's job, forever | ## When the native select wins - The options are **short plain text**: pay frequency, country of tax residence, employment type. - There is **one** value to choose and no need to search. - The list is **short enough to scan**, or ordered so type-ahead finds items quickly. - The main risk is on phones, where the platform picker is what people already know. For these, a custom build adds risk and cost without adding value. Most design systems style the closed control to match the rest of the form and leave the open list to the platform. ## When a custom listbox earns its cost - Options need **more than a label**: an employee's photo, name and job title, or a cost centre with its code and owner. - People need to **filter** by typing; at that point the component is really a combobox. - Several values are chosen and shown as **chips**. - The list is long enough to need **grouping, search or virtualisation** handled in one consistent way. The Authoring Practices add a caution: a listbox is not for interactive content. An option is read as a single flat string, so buttons or links inside options are not reachable in a usable way; a list of interactive rows needs a grid instead. ## What a custom listbox owes A team that builds one inherits obligations the platform used to carry: 1. **Keyboard:** Up and Down move focus between options; Home and End jump to the ends, strongly recommended above five options; **type-ahead** is recommended for all listboxes, especially those with more than seven options. 2. **Semantics:** the control has an accessible name distinct from its value, and each option exposes whether it is selected. 3. **Popup behaviour:** opening, closing on Escape, returning focus to the trigger, and staying on screen near the edges. 4. **Touch and small screens:** targets large enough, and a presentation that works with an on-screen keyboard open. 5. **Option wording:** short names, and no long shared prefix; the Authoring Practices note that repeating the same leading word on every option makes screen-reader users listen to it again and again. 6. **Testing:** keyboard alone, at least one screen reader per platform, zoom and large text. ## A middle path Many systems ship both: a thin wrapper over the native select as the default, and a custom listbox or combobox, often built on a headless component library that already implements the keyboard and semantics contract, for the cases in the section above. The documentation should say which to reach for, so product teams do not build a custom picker because the native one looked plain. ## Across platforms Native mobile platforms each have their own single-choice pickers, sheets and menus, and the web has its select. A cross-platform spec should define the **job**, one value from a fixed list, with name and value exposed, and map it to each platform's native control first.
- The brand team says the native select's open list looks off-brand; is that enough reason to build a custom one?Rarely on its own. The closed control, which people see most of the time, can usually be styled to match. The open list is a brief moment in which people expect their platform's picker. Weigh a small visual inconsistency against owning keyboard, screen-reader, touch and zoom behaviour indefinitely; for plain-text options the platform usually wins.
- Why should a listbox's options avoid starting with the same words?A screen reader speaks each option's whole name as one unit. If every option begins 'Germany - ...', users hear the shared prefix before the part that differs, again and again. The Authoring Practices suggest splitting such lists, for example country then city, so each list's options are short and distinct.
saying these in an interview costs you the question
- A custom listbox is always better because it can match the brand exactly.
- Native selects are inaccessible, so a design system should replace them.
- Buttons inside listbox options are a fine way to add per-option actions.
- Type-ahead is a nice extra that long lists can skip.
- Once a custom listbox passes an automated scan, it is accessible.