 and given that it's a framework, that
means _other_ sites will likely inherit disappointing accessibility stories
too.

And now it's back to drinking, which seems to be the only fix for this[1].

1\. Not really, but damn am I tired of a) fighting the same battles again and
again and b) answering the same questions about said battles again and again.
All of this stuff is exhaustively documented by folks who are smarter than I
am, so it isn't obscure, nor is it something I need to (or am even highly
_qualified_ to) answer.

~~~
du_bing
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.

~~~
ndarilek
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 specifi