Why Links Styled as Buttons Harm Semantic Web Design

Styling anchor links to look like buttons is a widespread design pattern, but it introduces critical usability, accessibility, and architectural issues in semantic user interface (UI) development. HTML provides dedicated elements for navigation and interaction for specific functional reasons. When developers disguise an anchor tag (<a>) as a button (<button>), they blur the semantic boundaries of the web, disrupt user expectations, and degrade the experience for people relying on assistive technologies.

Misaligned Roles and User Expectations

HTML semantics exist to communicate purpose. Anchor links are designed for navigation—taking a user from one URL or document fragment to another. Buttons are designed to trigger actions, such as submitting a form, toggling an interface state, or opening a modal dialog.

When a link is styled as a button, it creates a visual promise that the element performs an in-page action rather than navigating away. This mismatch creates cognitive friction. Users expect buttons to alter state immediately without a page refresh, whereas they expect links to load a new resource.

Accessibility and Screen Reader Disruption

Assistive technologies, such as screen readers, rely heavily on native HTML tags to announce the role and behavior of interactive elements. A screen reader announces an anchor link as a "link" and a button as a "button."

If an interface element looks like a button visually, sighted users expect button-like behavior. However, a visually impaired user navigating via a screen reader's rotor or element list will encounter the element categorized as a link. This inconsistency confuses users about what will happen upon activation. While developers sometimes attempt to patch this using ARIA attributes like role="button", this often introduces more problems than it solves, as it removes the native link behavior without fully replicating native button mechanics.

Inconsistent Keyboard Navigation and Activation

Browsers provide built-in keyboard controls based on semantic tags:

  • Anchor Links: Activated primarily using the Enter key.
  • Buttons: Activated using both the Enter key and the Spacebar.

When an anchor tag looks like a button, keyboard-only users intuitively try to trigger it with the Spacebar. For a standard anchor link, pressing the Spacebar typically scrolls the page down instead of activating the link. Re-engineering this behavior with custom JavaScript event listeners adds unnecessary code complexity to replicate functionality that native <button> elements provide by default.

Loss of Native Browser Features

Anchor links inherently offer features that buttons do not, such as:

  • Right-clicking to view context menus ("Open link in new tab", "Copy link address").
  • Middle-clicking to open the destination in a background tab.
  • Displaying the target URL in the browser's status bar upon hover.

Styling an anchor as a button often leads users to believe they cannot perform standard link interactions. Conversely, using an anchor styled as a button for an action that does not actually change the URL (such as utilizing href="#" or href="javascript:void(0)") breaks context menus entirely and clutters the browser history if misused.

Maintenance and State Handling Overhead

Native buttons include built-in states, such as the disabled attribute, which automatically prevents focus and click events while communicating inactivity to accessibility APIs. Anchor links do not natively support the disabled attribute. Disabling an anchor link requires removing the href attribute, adding aria-disabled="true", preventing default click events in JavaScript, and manually handling focus states. This introduces fragile, redundant code compared to using native elements as intended.

To maintain a robust semantic UI, design systems should align appearance with underlying function: reserve anchor links for navigation to unique URLs, and reserve buttons for user actions that alter application state.