"Can we make this checkbox a green check mark to match our brand colors?" "We also want the select dropdown arrow to match the design." In client web development, requests to align form controls with brand styling never cease. The trouble is that the traditional approach to meeting these requests has long been to "hide the standard browser checkboxes and selects, rebuilding their visual appearance from scratch using <div> and JavaScript." While the visual design aligns, the cost is severe: keyboard navigation, screen reader accessibility, standard smartphone UI behaviors, and native form submission handling—all features the browser provided out of the box for free—must now be re-engineered from scratch. Any implementation flaw directly creates users who cannot complete the form.
The ways to avoid this "rebuilding" have grown significantly in recent years. As noted in CSS-Tricks' summary, What’s !important #12: ::checkmark, HTML Anchor Positioning (CSS-Tricks), the advent of accent-color, ::checkmark, and the ability to style select contents with CSS opens up a path to style native controls directly without hiding them. In this article, we examine how to balance a brand-aligned aesthetic with unbreakable accessibility from a web development perspective.
Why rebuilding native controls turns into technical debt
Hiding native form controls and building custom replacements forces you to shoulder everything beyond mere visuals.
First is rebuilding accessibility from scratch. Native <input type="checkbox"> and <select> controls can be operated via keyboard, and screen readers correctly announce them as "checkbox, unchecked." Rebuilding these with <div> means you must reproduce all of these behaviors yourself; if anything is omitted, some users won't be able to interact with them.
Second is the loss of native platform UI. On smartphones, native select elements bring up the operating system's drum-style picker wheel. Custom implementations throw away this smooth, comfortable native UI, frequently resulting in proprietary dropdowns that are difficult to use on small screens.
Third is the maintenance burden. With custom components, you must continually track browser specification updates and novel input methods yourself. In client development, maintaining what the browser was supposed to handle for you becomes a heavy, long-term liability.
Styling native controls directly avoids all three of these pitfalls entirely. Accessibility, standard UI, and submission mechanics remain handled by the browser, while CSS simply layers on the visuals. The mindset that "it is far more dependable not to break accessibility from the start than to retrofit it later" directly connects to the concepts we covered in our article on accessible forms and navigation.
Start with accent-color: reflect brand colors in a single line
The most effortless approach is accent-color. It lets you change the active accent color of checkboxes, radio buttons, and progress bars to your brand color in just one line.
/* チェック済みの色などを、まとめてブランドカラーに */
:root {
accent-color: #176B87;
}With just this, the native checkbox remains untouched—preserving full keyboard navigation and screen reader support—while its color cleanly aligns with your brand. What once required dozens of lines of code and JavaScript in custom components can now be achieved in a single line of CSS without breaking anything. In most client projects, this alone satisfies the vast majority of requirements.
Taking it further: custom check marks and select elements
Even when you need to customize beyond color—such as styling the shape of the check mark or the contents of a select menu—it is now possible to dive deeper while preserving native controls. For checkbox and radio styling, after applying appearance, you can craft custom shapes using pseudo-elements or ::checkmark. For select elements, where browser support allows, you can style the opened dropdown list using CSS, achieving styles that once required custom JavaScript dropdowns right on native <select> elements.
| Common styling request | Approach | What is preserved |
|---|---|---|
| Change the checked color | accent-color | Native operation and screen reader announcements remain intact |
| Change the check mark shape | appearance + pseudo-elements / ::checkmark | Remains a native checkbox |
| Style select arrow and options | Customizable <select> | Native mobile UI and submission behavior |
The key takeaway is that none of these approaches discard the native control. Even as you enhance the visual presentation, the underlying foundation remains the browser's native <input> and <select>. Consequently, they remain fully operable via keyboard and accurately communicate with assistive technologies. For styling features that do not yet enjoy universal browser support, confirm that unsupported environments gracefully fall back to pristine native controls before adopting them. The criteria for deciding whether to adopt new features based on support status follow the exact principles discussed in our article on modern CSS native features.
Pitfalls When Integrating Agents in Custom Development
On a member registration form project that GleamHub took over for remediation (client name withheld), all checkboxes and select dropdowns had been built as custom JavaScript components. While visually aligned with the brand, certain items could not be selected using only the keyboard, and on smartphones, the select options overflowed off-screen. Usability had been sacrificed for the sake of design.
We reverted these custom components back to native <input> and <select> elements, then rebuilt the styling using accent-color and pseudo-elements. The checked states matched the brand color, the OS-native picker wheels were restored on smartphones, and every input could once again be operated via keyboard alone. All we did was return component behavior to the browser where it belonged, leaving only the visual layer to CSS.
What proved most effective in this project was the principle of "never abandoning native controls for the sake of visuals." In an era where styling can be layered on with CSS, there is virtually no reason to build behavioral mechanics from scratch. Note that when adjusting colors with accent-color, ensuring the selected state can be discerned through check mark shapes or text—not color alone—is courteous to users with color vision deficiencies. Combining form label and state accuracy with the insights from our article on structuring names for screen readers helps you achieve visual elegance alongside genuine usability.
Where to begin
When you want to restyle form controls, making the deliberate choice to stop hiding and rebuilding native elements is the first step toward forms that are easy to use and maintain. Color adjustments take just a single line of accent-color, and custom shapes or select styling can largely be achieved via CSS while keeping native controls intact. Doing so reduces JavaScript, automatically preserves keyboard navigation and native mobile UI, and eliminates confusion for future maintainers.
As a first step, we recommend picking one checkbox currently implemented as a custom component, reverting it to a native <input type="checkbox">, and applying color using accent-color. Once you verify that it meets visual requirements and functions flawlessly across keyboards and smartphones, it is ready for production.
Whether you are struggling with custom form components to match brand styling, worried about accessibility and mobile compatibility in legacy custom controls, or striving to balance aesthetics with usability, please reach out via GleamHub's contact form. We will review your current form implementation, identify which parts can be returned to native controls and styled with CSS, and rebuild them into a lightweight, resilient structure.
