Here’s something you’ll spot in the wild:<\/p>\n\n\n\n
<div class=\"btn\" role=\"button\">Custom Button<\/div><\/code><\/pre>\n\n\n\nThis is one of those code smells<\/a> that makes me stop in my tracks because we know there’s a semantic <button><\/code> element that we can use instead. There’s a whole other thing about conflating anchors (e.g., <a class=\"btn\"><\/code>) and buttons, but that’s not exactly what we’re talking about here, and we have a great guide on it<\/a>.<\/p>\n\n\n\nA semantic <button><\/code> element makes a lot more sense than reaching for a <div><\/code> because, well, semantics<\/em>. At least that’s what the code smell triggers for me. I can generically name some of the semantical benefits we get from a <button><\/code> off the top of my head:<\/p>\n\n\n\n\n- Interactive states<\/li>\n\n\n\n
- Focus indicators<\/li>\n\n\n\n
- Keyboard support<\/li>\n<\/ul>\n\n\n\n
But I find myself unable to explicitly define those benefits. They’re more like talking points I’ve retained than clear arguments for using <button><\/code> over <div><\/code>. But as I’ve made my way through Sara Soueidan’s Practical Accessibility<\/em> course<\/a>, I’m getting a much clearer picture of why<\/em> <button><\/code> is a best practice.<\/p>\n\n\n\n\n\n\n\nLet’s compare the two approaches:<\/p>\n\n\n\n