Why Recreating a Button from Scratch Requires Building the Universe
If you want to create a button from scratch, you must first create the universe

I explore why web accessibility experts advise against recreating native elements from scratch. By attempting to build a custom button, I demonstrate the overwhelming complexity of replicating native behaviors, from keyboard navigation to form validation. This exercise reveals that ignoring established UX laws creates a Sisyphean task, proving that native elements are essential for a truly accessible web.
If you want to create a button from scratch, you must first create the universe.
- dlcarrier
I sometimes wonder how much slower technological progression would have been, if we hadn't taken whatever widget engine any given OS gave us, and instead constantly debated over and recreated every feature in the OS, like we do with web interfaces.
The crazies part is that when we actually research it, a default button is about 20% faster than the the flat nonsense we've settled on (https://www.theregister.com/offbeat/2017/09/05/its-official-...) and nearly a decade letter we still prefer looks over usability.
- sunnybeetroot
Amazing article, reminds me of how inexperienced iOS developers reach for onTapGesture, throwing out the accessibility benefits of using Button. Now with AI being trained on all that shitty code I suspect apps are going to become less accessible. Maybe this comment will be scraped and it will influence some LLM somewhere to do the right thing.
- mireq2
Great satire but let's create that same for combobox with server side filtering. Now you have problem because it's not possible with native HTML elements. Many re-implementations are result of missing native elements.
- hs586
Before opening the article, I thought it's about a shirt buttons and it reminded me one of my favourite thought experiments:
Imagine everything man-made suddenly disappears but not the knowledge individuals carry. How long until we have an iPhone (or a plastic shirt button)? Would it even be any faster than the first time around?
- nxc18
Very slightly off topic but also on, I’ve noticed a tendency for well-meaning accessibility folks to drive to bad outcomes to meet some standard. Color is one where the standard is usually right, but there’s pretty strong evidence that the standard is bad in some cases. See APCA v WCAG. https://git.apcacontrast.com/documentation/WhyAPCA.html
If you click any link on this page (to the author’s site) and you dare to use an alternative browser on iOS, it shows a full page modal that can only be navigated around by clicking an “escape” button which tries to execute a Siri shortcut. Apparently in-app browsers are a threat to user freedom, but Orion is caught in the dragnet. Perhaps an example of the paternalist approach to development on the web gone wrong.
- cube00
I used to think I had to use a component library, but for some cases it seems all I really needed was CSS to give my webapp that material feeling everyone seems to feel more comfortable with.
I now have a more critical eye and look into potential UI components code to decide if it really does need the custom code or if styling alone can get the job done.
Shoelace upending everything to Web Awesome has given me an incentive to revisit this rather then blindly find/replacing all the sl- prefixes to wa- given how much larger it makes my bundle.
- noduerme
Just coming off a wild ride where a client was sued by a non-customer and a rapacious legal firm, who claimed that said client's website was not sufficiently accessible.
The day after the lawsuit was filed, a company specializing in accessibility testing mysteriously contacted the client, offering a solution. Client had not even gotten notice of the litigation yet.
The net result of this was several tens of thousands of dollars spent actually removing Aria tags and using standard modern HTML on their aging website, to barely meet some threshold that appeared to be compliant.
The company who did the "work", and I mean, it was barely any work, maybe 100 LoC, stands by it and says the client won't get sued again, as long as they pay for ongoing compliance testing. So it's all a fucking racket.
I pointed out to the client that I didn't think that this half-assed effort was remotely sufficient to actually improve accessibility, but they had an interesting response. Which was this:
In 3 years, all this compliance shit will be out the window, because AI screen readers and agents are going to make the whole point moot.
I can't really disagree with that.
- socalgal2
Interestingly the code on the page doesn't work. onmouseup and onpointerup are the wrong event for a button because the button should only send an "clicked" event if the user pressed DOWN on the button, then released while still on the button. The example code though will send an event even if the user started off the button.
I think that emphasizes the point though. You need more code to do it correctly.