A CSS Class Doesn't Change What an Element Does
It's easy to style any element — a <div>, a <span>, a link — to look exactly like a button, since visual appearance comes entirely from CSS. But the underlying HTML element still determines how the browser, keyboard navigation, and screen readers actually treat it, regardless of how it looks.
Use <button> When It Performs an Action
A real <button> element is the right choice whenever clicking it triggers something happening on the current page — submitting a form, opening a modal, toggling a setting, running a calculation. Buttons are automatically keyboard-accessible (reachable via Tab, activatable with Enter or Space) and correctly announced by screen readers as buttons, without any extra work.
Use <a> When It Navigates Somewhere
An <a> element, styled to look like a button, is the right choice whenever activating it takes the user to a different page or a different location — including a different section of the same page via an anchor link. Links support behaviors buttons don't: opening in a new tab, being copied as a URL, or being bookmarked directly.
Why This Distinction Matters Beyond Aesthetics
A <div> or <span> styled to look like a button but lacking the actual semantic element requires manually re-implementing keyboard accessibility, focus handling, and proper screen reader announcement — functionality real <button> and <a> elements already provide automatically. Using the correct native element from the start avoids this extra, easy-to-get-wrong work entirely.
A Simple Test
Ask what happens when the element is activated: does the page navigate somewhere (use a link), or does something happen without leaving the current page (use a button)? This single question resolves the choice correctly in the large majority of cases.
Ready to style either element with the same visual polish?
Open CSS Button Generator