Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Incredible, thanks for sharing your unique experience, I don't know the difference of <div class="ui button"> and <button class="ui button"> when I use Semantic-UI, because they show the same thing. According to your declaration, I think from now on I will better use the latter one.


1. The div is not keyboard-focusable by default, so you need to add `tabindex="0"`. 2. By default, the div does not trigger click on Enter/Space, so you need to add a keyup handler to make it do so. 3. Screen readers won't report the div as a button because they can't identify widgets based on how they look, so add `role="button"` as per the ARIA spec (only on first cup of coffee now, so I'm not providing a link.)

Yes, it isn't super complicated, but a) most don't do it because they look identical and b) multiply that by any other widget where the HTML version is replaced with a div and suddenly things get complicated. If you're not a keyboard user, you may not understand how the web works without a mouse. All that is lost when switching to divs.

This says nothing about how OS/screen reader combinations differ in key handling, nor about how complex widgets such as multiselects include similarly complex key handling. Also, the above ARIA is super simplistic. It doesn't handle situations where, for instance, you have multiple roles and have to toggle some of them based on what item is selected, what item is focused, etc.

So, TLDR: It's so much better to use the HTML elements specifically designed for a certain task because you get a lot for free that is taken for granted. That said, I like how Semantic specifies how my UI might look, an wish I could have the best of both worlds.


And a custom button is certainly not the worst offender, though it's probably the most commonly cited example. A blind friend just needed sighted help to complete a purchase, because the process included a custom checkbox with no ARIA support. At least with a button that's not identified as such, the user can figure out that it's a button from the name and context, and use their screen reader's ability to simulate a mouse click. Unless the buttons are implemented using spans rather than divs, and there's more than one of them in the same block element.


Great sharing, it seems that HTML tags are safer and more robust.


This really broadens my mind, HTML tags have such functions, thanks, good to hear that.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: