Inventing the Wheel

#a11y #uidesign #html #frontend

This article is about HTML, native elements, and custom-built components.
It touches on several important areas: quality, time and cost, accessibility, maintainability, and the risk of introducing bugs.

To explain the concepts, I'll use an analogy.

We are a car company, and we're about to build a new car model. Something that really stands out. Something that signals innovation and boldness. A clear identity!

Then we reached the point where we had to decide on the wheels and tires. Our thinking was this: ordinary wheels felt... a little generic. So expected! Round wheels are the standard. They do their job, sure, but what about the brand?

Our logo, though, an octagon badge, is so unique and modern. What if the wheels could mirror that? Octagonal wheels! That's bold for sure. A clear identity. We'd be the first!

We designed it, built it, and launched it. It looked incredible. Then people started driving the car.

“It feels a little shaky.”

“Is it supposed to be bouncing like that?”

It turns out, we learned, that octagonal wheels don't roll quite as smoothly as round wheels. But we could fix it. We brought in a partner to help minimize vibrations. One extra layer that smoothed out the ride. It was an elegant solution built on top of our innovation. It took a few months, but we were happy with the result.

Then customers started reaching out - they couldn't change the tires. Standard tools no longer worked. We shifted our priorities: changing tires had to be possible. We developed adapters, updated workshops, and solved the logistics.

Other problems surfaced along the way: clunking noises in the front end, high wear on highways and uneven braking performance. But there was nothing we couldn't solve. After all, we are a top brand. In retrospect, we realized that every solution required time and resources.

</analogy>

Ok - this isn't about cars.

This is about how we build things on the web. Standards don't exist to limit creativity. They exist because they work, and continue to work, thanks to many iterations over many years.

Round wheels are what we already have. They are tested, reliable, and compatible.
Octagonal wheels are what we build to make something feel more unique or more like “our brand.” And as a general rule, it means we need to spend extra time making them work as well as standard wheels.

Websites work in a similar way. HTML already comes with built-in components. Native, as it were. They are standardized across browsers - not as a limitation, but as a strength. They are robust, well-tested, and familiar to users. Developers, designers, and content creators benefit from understanding what is available out of the box.

When we choose to build our own versions of something that already exists, we often take on more than we initially expected. I know this because I, as a frontend developer / WAS, have built and audited several custom solutions over the years.

Examples of custom components include select dropdowns, buttons, checkboxes, toggles/switches, tooltips, date pickers, progress indicators and more.

If you understand the requirements needed to reach the same level, you can build a custom component. However, be aware that it takes time. Or, instead, you can use that time to build value elsewhere:

Performance
Security
SEO
User testing
Error handling
Documentation
Automated testing
Edge cases
Dealing with technical debt

Does this happen in real life?

The example with octagonal wheels is obviously exaggerated and a little silly. But yes, it happens. More often than you might think. Many web solutions and UI libraries contain their own implementations of things that have already been solved a long time ago.

Not every native HTML component can be styled exactly however we want. And sometimes there is a good reason for that.

Visually, there are many hacks and tricks we can use. Soo many. But interfaces are more than what we see with our eyes. Structure and semantics, what something is, are just as important as how it looks.

Because in the end, it is rarely about whether we can build something. Usually, we can. The question is why we should. And if the main reason is that the standard solution feels boring, it may be worth reconsidering.

And just as I was finishing this article, I spotted this car in the supermarket parking lot.