Striking a Balance Between Native and Custom Select Elements

This article discusses how to build a styled drop-down selection element that is both beautiful and accessible. We will cleverly combine the native<select></select> Elements and custom styles for the best user experience.

Importance of Name: Drop-down list, menu, navigation

During the research process, we found that terms such as "drop-down list", "menu", and "navigation" are often mixed, resulting in ambiguity. This article will clearly define the "drop-down list":

Drop-down list: An interactive component containing a button to show and hide a list of items, usually triggered by a mouseover, clicking, or tapping. The list is hidden by default and displayed after interaction. Lists usually overwrite other content in the form of blocky content (i.e. options).

Many interface elements look like drop-down lists, but simply referring to them as "drop-down lists" is as general as describing animals with "fish". We need to distinguish between three different types of drop-down lists: menu, navigation, and select elements:

• Menu: List of commands or actions that users can execute in the page content.
• Navigation: A list of links used for website navigation.
• Select: Form Control (<select></select> ), used to display a list of options for user selection in the form.

Different users have different ways of perceiving and interacting with the interface, so there is subjectivity in the naming of UI elements and the definition of design patterns.

<menu></menu> Elements are deprecated and are not recommended. For detailed instructions on the included menu and menu buttons, and why the ARIA menu role should not be used for site navigation, please refer to the relevant resources.

We will focus on<select></select> The drop-down list type of the element.

<select></select> The style challenge of elements

According to MDN, there are three situations: "good, bad, and ugly".<select></select> Elements undoubtedly fall into the category of "ugly", and their styling support is insufficient, which leads developers to often seek alternatives.

Ideally, if you can avoid it<select></select> , it should be avoided. However, in some cases,<select></select> Still the best choice, such as numerous options, limited layout space or insufficient time/budget.

Customize<select></select> The demand

Create custom<select></select> When you are in the process of meeting the following requirements:

• The button displays the currently selected option.
• Click the button to toggle the visibility of the option list.
• Clicking on the option list will update the selected value, the button text changes accordingly, and the option list will close.
• Clicking outside the component will close the list of options.
• The trigger contains a triangle icon pointing downward indicating that the option exists.

However, this only meets some of the needs. Native<select></select> The element also provides the following functions:

• Regardless of the user's visual ability, the selected options are clearly visible.
• Components are able to interact with the keyboard in a predictable way (e.g., use arrow keys to navigate, Enter keys to select, Esc keys to cancel, etc.).
• Assistive technologies (such as screen readers) are able to clearly announce elements to users, including their roles, names, and status.
• Adjust the position of the option list (i.e. it will not be clipped by the screen).
• Elements adhere to user's operating system preferences (such as high contrast, color scheme, animation, etc.).

Many customizations<select></select> No component can fully meet these needs.

Build a "hybrid" selector

Build simple customization<select></select> Will sacrifice functionality in exchange for aesthetics. A better way is to provide native by default<select></select> , and replace it with a more beautiful custom version where possible. This is the philosophy of the "hybrid" selector. It contains two selectors:

• Native<select></select> , visible and accessible by default.
• Customize<select></select> , hidden by default, only displayed when using the mouse.

Here is an example of HTML structure:

 <label for="selectNative">Main job role</label>
<div>
  <select id="selectNative" class="selectNative">
    <option value="1">Option 1</option>
    <option value="2">Option 2</option>
  </select>
  <div class="selectCustom">
    <!-- Custom select content -->
  </div>
</div>

The CSS code is used to control the display and position of the two selectors:

 .selectNative,
.selectCustom {
  position: relative;
  width: 22rem;
  height: 4rem;
}

.selectCustom {
  position: absolute;
  top: 0;
  left: 0;
  display: none;
}

@media (hover: hover) {
  .selectCustom {
    display: block;
  }
  .selectNative:focus .selectCustom {
    display: none;
  }
}

JavaScript code is used to handle click events, synchronize the values ​​of two selectors, and keyboard navigation.

Usability testing

We conducted a small usability test, which included people with disabilities, tested using different equipment and assistive technologies. Test results show that the method works, but more extensive testing is still required.

The advantages of this method are:

• Mobile and tablet users get native<select></select> , providing better user experience and performance.
• Keyboard users are able to be native in the expected way<select></select> Interaction.
• Assistive technology can be native like normal<select></select> Interaction.
• Mouse users are able to enhance customization with<select></select> Interaction.

This method provides all users with the necessary native functionality without the need for additional work to implement all native features.

However, this approach is not omnipotent, it works with simple selectors and may not work for complex interactions.

About selectors for similar menus

If the selector always has selected options (such as sorting content), then native can be used<select></select> Or customize the menu. Pay attention to the input criteria of WCAG 3.2.2:

Changing the settings of any user interface component should not automatically cause context changes unless the user has been informed of its behavior before using the component.

To meet this criterion, you need to warn the user before the user interaction, or add instructions after the selector.

Conclusion

Building a truly accessible selector component is harder than it seems. The "hybrid" selector is one way to try to get as much native functionality as possible while maintaining its aesthetics. If resources allow, make sure to conduct adequate testing before releasing the components.

Remember to use the correct name when creating the "drop-down list" component. ?

The above is the detailed content of Striking a Balance Between Native and Custom Select Elements. For more information, please follow other related articles on the PHP Chinese website!