It's worth noting that VoiceOver is well-known for being a lot more lax than most other screen readers. Other options tend to be a lot more strict around standards and what they'll announce.

I would literally never use <input type="submit|button"> for anything when the <button> element is an option, personally.

That was a big part of "thought leader guy"'s argument in favor of divs, but not the only one.

The most common reason I've seen is whining about having to override default button styles.

I too have encountered this reasoning.

Then I write some basic CSS and show them they have nothing to fear.

Yet, I still remain irritated beyond belief that its such a common thing. In 2025. Hell, in 2017!

I don't know what to do about it, other than constantly remind people about things, but it gets tiring.

Though, its a great interview question. Its a quick way to understand if someone knows the fundamentals or not.

Kinda like how people got ".bind" wrong on functions for years.

Literally absolutely never ever do this.

I probably should have included "if you're building for the frontend you should probably know CSS". Good follow-up piece. Thanks for mentioning it!

It's the default for buttons inside forms, but it's SO trivial to add type="button" than any argument that div's are a better choice because of this should be dismissed as unserious trolling out-of-hand.

No. Objectively no.

It is INFINITELY easier to add type="button" than all of the other shit I mentioned in my article.

Just curious, what does it mean for something to be "infinitely easier" than something else? :-)

Hey, it's me, the original author!

The issue isn't with tabindex=0 specifically, but fucking with tabindex in general. People go down that path, and start putting that shit on everything, like it's Frank's Red Hot.

And in my experience, the same folks who use div's instead of button's are the ones who don't know better and start throwing tabindex around.

"why do you need to listen for events at the document level?"

Not events generally, keydown events specifically, which do not fire on child elements of the document.

Not sure about that, MDN's example shows keydown being attached to an element.

https://developer.mozilla.org/en-US/docs/Web/API/Element/key...

Hi, good premise overall, but there are just a lot of little things that are off.

- It only counts as "fucking with tabindex" if you give it a value that's not 0 or -1. You should give that specific disclaimer, because there are uses for tabindex=0 other than reimplementing <button>.

- Divs can definitely receive keydown events. If I go to an arbitrary web page, pick a div and run `div.tabIndex = 0;` + `div.addEventListener('keydown', console.log);`, I see those events coming through when I have the div keyboard-focused.

- "Run your code, somehow..." I think just calling `notRealBtn.click()` is the best option.

- Stupid but semi-interesting nitpick: 'keydown' is good for enter, but you should be listening to 'keyup' for the space bar. That's how real <button>s work anyway.

- The 'keyup' listener should call event.preventDefault() to prevent the default behavior of the space bar scrolling the page.

> Not events generally, keydown events specifically, which do not fire on child elements of the document.

Are you sure? I have a 17 year old HTML tool written using plain, vanilla JavaScript where keydown on a child element seems to have been working as expected.

https://susam.net/quickqwerty.html

https://github.com/susam/quickqwerty/blob/1.2.0/quickqwerty....

Nice article, by the way!

I think that’s because it’s an input and not a div, so it can get focus. Im not sure whether tabindex is enough to make a div do that too, article suggests no