How can I keep native select controls accessible when styling them?

A native select represents a menu of options, is typically associated with a label, and provides browser and operating-system interaction. Keyboard mechanisms can vary across browsers and operating systems, so don’t assume one test covers every environment you support. [S1]

Keep an understandable label associated with the control, and make sure the choices and selected value remain legible. Then check that a keyboard user can reach the select, change its choice, and tell when it has focus.

For example, a form might have the label “Delivery method” and the options “Standard” and “Express.” If you change the border, padding, or arrow, check that the label, choices, and focus state are still easy to see.

Yes, to change how the widget is rendered—but it does not replace the select with a custom widget. appearance: none removes some native styling while retaining native functionality and interactions. Some parts may become visually absent, so provide a visible design yourself. [S2]

For example, you could give the select a border and padding, then add a visible focus style. Check that the chosen value is not clipped and that any arrow does not cover the text. Don’t remove the focus outline without providing a focus treatment that is easy to see.

select {
  appearance: none;
  border: 1px solid #555;
  padding: 0.6em 2em 0.6em 0.7em;
}

select:focus-visible {
  outline: 3px solid #165fcc;
  outline-offset: 2px;
}

This is a starting example, not a guarantee: check the styling and focus visibility in your own design and target environments. [S2]

Test the styled control in the browser and device combinations you support. Because native select keyboard mechanisms can vary, check the actual behavior in those environments rather than relying on one assumed sequence. [S1]

Try this practical pass:

1. Reach the select using the keyboard and check that focus is obvious.
2. Use the available keyboard interaction to choose an option; confirm the selected value is visible.
3. Move focus away and back. Check that the control still looks present and its focus state remains visible.
4. Repeat in your supported environments, checking that the text or arrow is not clipped.

Also check that the label explains the choice and is associated with the control. Native selects are typically associated with labels, but you still need to verify your own markup. [S1]

Prefer a native select if it meets your needs. Consider a custom control only for a specific requirement the native control cannot meet, and only if you can implement and test its interactions. Changing native styling alone does not create a replacement interaction model. [S1]

Before deciding, write down what the native control cannot do for your use, which environments you need to support, and how the custom version will provide keyboard access, visible focus, a clear label, and an understandable selected value. Compare that work with keeping the native control. MDN mentions base-select for customizable selects but notes that support for parts of the feature can vary; check your target environments before relying on it. [S2]

A short decision note could say: “Keep the native select unless [specific need] cannot be met. Test labeling, keyboard operation, selected-value visibility, and focus in [target environments]. If proposing a custom control, document how you will provide and test those interactions.” Whether a custom control is accessible depends on its implementation and testing.