There’s no question that a majority of the time, there’s a ton of value in creating custom components for your webapp. Custom components should aid in a user’s experience with your product, which ultimately serves to reinforce your brand. You can’t effectively deliver on your product’s value proposition while married to the Bootstrap brand.

So you think, that’s great! I’m on board, let’s customize all the things! And I really mean, ALL THE THINGS. Let’s build our very own special snowflake checkboxes, radio buttons, dropdowns, combo boxes, number sliders, number steppers, date pickers, color pickers, email inputs, scrollbars, file uploaders... because BRANDING!

I’m being a bit facetious. But just because you can customize something, doesn’t mean you always should.

You’re almost certainly breaking accessibility

The big offender in this category are mainly user input controls; components that browsers have already decided how they should generally look and behave. It’s one thing to decide that your input fields should have a blue border and a font size of 14px, but it’s an entirely different story to decide you want to create a numeric input field with a custom stepper control.

In a situation like this, customized input components may look similar to standard HTML form elements, but are created using non-standard HTML for presentational reasons. Writing semantic HTML that describes your content is important to accessibility, because as soon as you start adding markup for the sole purpose of producing a visual effect, behavior you used to get mostly for free is now broken.

Custom components can become unusable for users relying on assistive technologies

Let’s say you’re creating a custom dropdown input field. In order to produce the desired visual design, you had to introduce some additional, non-semantic markup. As a result, the component is no longer tabbable and users can’t change the input via keyboard navigation. Many users have come to expect that things like dropdowns should open when they hit the Enter key or the Spacebar; when you deviate from well-established expectations, your components become unusable for many people.

For users who rely on screen readers, your non-semantic markup means they have no idea that your component is even a dropdown. The screen reader can’t advertise that there is a list of selectable options, whether or not it is open or closed, and which option is selected. To the user, it may seem like a completely unrelated set of buttons, because that’s how the screen reader reads them out loud.

Custom components can be unintuitive to sighted users

You might not just be breaking expected behaviors — you may also be breaking expected affordances. For example, a really common one that I see overridden all the time is the outline property. Often seen as a bright, fuzzy blue line around an element, it’s not there just for show. It indicates to the user that the element is currently in focus, it is in the tab order of the page, and that it is interactable. Getting rid of the outline means users can’t tell where in the page they are or what they can interact with.

Considerations should be made for both mobile and desktop users, as well, because they make use of different affordances. With mobile in particular, native input controls have been carefully designed in recognition of the need for a larger target clickable area. It’s not generally a good idea to mess with something that already works well and is meeting users' needs.

The cost to implement the component exceeds the value added

If you’re going to build a custom component right, it may require (re-)implementing the behaviors and affordances a user would expect to see from various browsers and operating systems. Depending on the visual design, this could be a non-trivial amount of work, so it’s important to understand if the value your custom component brings to the user is worth that effort.

It’s not just about development effort, either; since “correct” behavior is dependent on browser and operating system, it also significantly increases the cost of manual and automated testing in order to mitigate the risks we have introduced. You may need to invest in new automated and manual testing procedures to verify behaviors at the appropriate level.

A common example of a custom component where the cost may exceed the value is a datepicker. There are many datepicker libraries out there in the wild, and there are just as many reasons why developers decide against them and declare they want to write their own. Datepickers are most definitely not a trivial thing to build, and it’s likely they are just a small part of your product ecosystem. What benefit are you getting from your custom datepicker over the alternatives? Is it a priority in order for your product to go live? Chances are... probably not.

The developers don’t know what they’re doing

The development team may not necessarily have the expertise to ensure they are meeting the required accessibility standards level set by the business, but don’t let that be an excuse to not address accessibility concerns. That would be alienating a whole lot of people, and in some cases could even get the business sued.

Creating custom components requires an even greater attention to detail. It requires specific kinds of user testing with people who are experienced in using assistive technologies on a regular basis. A Subject Matter Expert in accessibility may be required to advise the development team. These are good practices to follow for any project in general — whether we care about accessibility at all isn’t really up for debate, honestly — but it becomes more of an imperative with high degrees of customization. You probably don’t know how to use a screen reader effectively if you don’t rely on it every day. It’s good to recognize where your knowledge gaps are, and to ask for help so you can improve the lives of all your users.

And while getting all this feedback is awesome and great, it is important to remember that this is also a part of the cost of development.

So... should we build custom controls?

It’s almost always better to use native controls when you can, with just enough styling to still fit in with your theming. At first glance, it could seem trivial to implement the customized components, since we can do so many cool things with CSS and Javascript these days, but it’s important to be aware of how your visual design could be hurting you in other ways. That being said, there are plenty of valid reasons why you may not want to use native controls, though, and as long as your team is aware of the costs and agree that the value is worth the effort, then I’m not here to rain on your parade!