Buttons vs. Links: Choosing the Right Element

• Implicit ARIA roles. <a href> maps to role="link" and <button> to role="button" in the accessibility tree. Remove the href and an <a> has no role (it’s “generic”) and drops out of the tab order.
• Activation behavior. The HTML spec gives each element its own activation behavior. Links navigate while buttons run their form-owner behavior (submit/reset/etc). That’s why Space activates buttons but scrolls the page on a link.
• Navigation is a browser feature, not your code. A real link participates in history, :visited, prefetch, link-hover status text, modifier-key clicks and “open in new tab”. A click handler that calls location.href = … or router.push() reimplements one sliver of that.
• The mental model screen reader users rely on. Users pick their keyboard command based on the announced role. Mismatches cost them time even when the action still technically works.

• HTML type values. submit (the default inside a <form>), button (no default behavior) and reset (clears the form, and is rarely worth the risk of lost work). A button outside a form can still submit one via the form="form-id" attribute.
• State lives in ARIA.
  • Toggle: aria-pressed="true|false", with a constant label (“Mute”, not “Mute”/“Unmute”). Changing both the label and the state double-signals and confuses users.
  • Disclosure: aria-expanded plus aria-controls pointing at the region.
  • Menu button: aria-haspopup="menu" + aria-expanded, and the menu itself must implement arrow-key navigation per the ARIA Authoring Practices menu pattern.
  • Dialog trigger: move focus into the dialog on open, trap it there, and return it to the trigger on close. Native <dialog> with showModal() handles most of this.
• disabled vs aria-disabled. Native disabled removes the button from the tab order and blocks events, so keyboard and screen reader users may never discover it or learn why it’s off. aria-disabled="true" keeps it focusable and announced; you block activation in code and can explain the reason. For form submit buttons, many teams prefer leaving them enabled and showing validation errors instead.
• Loading states. Keep the button’s width stable, set aria-busy="true" or announce progress via an aria-live region, and guard against double submission.
• Split buttons are two buttons (the action and the menu trigger), each needing its own accessible name.

• Router links. <RouterLink> and <NuxtLink> render a real <a href> and intercept the click for client-side navigation. You keep every native link behavior and get SPA speed. NuxtLink also decides internal vs external for you and prefetches route chunks.
• Current page. Mark the active nav item with aria-current="page" (router links can add this automatically). Don’t rely on bold or color alone.
• In-page anchors and focus. Browsers move scroll position, and modern ones move the focus starting point, to the target. If the target is a non-interactive element and focus doesn’t follow in your setup, add tabindex="-1" to it. With sticky headers, set scroll-margin-top so the target isn’t hidden.
• target="_blank" and rel. Modern browsers imply rel="noopener" for _blank, which blocks the new page from controlling yours via window.opener. Add noreferrer if you don’t want to leak the referring URL. Announce the new tab in text or with an icon that has a text alternative (WCAG 3.2.5 is AAA, but the courtesy matters).
• download only works for same-origin URLs (or blob:/data:); cross-origin it falls back to normal navigation. The server’s Content-Disposition header can override it.
• Visible label vs aria-label. If you add aria-label, it replaces the visible text for screen readers. Voice-control users speak what they see, so the accessible name must contain the visible words (WCAG 2.5.3, Label in Name). Visually hidden extra text is usually safer than aria-label on links.

• How the accessible name is computed. In order of precedence: aria-labelledby, then aria-label, then the element’s content (text, plus alt on images inside it), then title as a last resort. Know this order when debugging “why does it say that?” in the browser’s accessibility tree panel.
• The first rule of ARIA: don’t use ARIA if a native element does the job. role="button" on a <div> changes the announcement but not the behavior: you then owe tabindex="0", Enter and Space handling, and disabled handling. Use ARIA for state (aria-pressed, aria-expanded, aria-current), not to turn one element into another.
• Don’t nest interactive elements. A <button> inside an <a> (or vice versa) is invalid HTML and announces unpredictably across screen readers.
• Test with real tools. Keyboard only, then VoiceOver (macOS/iOS) or NVDA (Windows), plus an automated checker like axe. Automated tools catch roughly a third of issues; the role/behavior mismatch is often one they miss.

• A “Sign up” call-to-action styled as a big button. If it goes to /signup, it’s a link with button styling. That’s correct. Style follows design; element follows behavior.
• Submit, then redirect. “Save and continue” sends data and then navigates. The user’s action is the submit, so it’s a button. The navigation is a consequence.
• Tabs. If each tab swaps a panel in place, it’s the ARIA tabs widget (tablist/tab/tabpanel roles, arrow-key navigation). If each “tab” is its own URL, it’s a <nav> of links with aria-current="page".
• Pagination, sorting and filters. If they update the URL (and they usually should, so results are shareable and Back works), they’re links. If they’re purely local UI state, they’re buttons.
• Whole-card click targets. Don’t wrap the entire card in <a>: the link name becomes the whole card’s text, and nested buttons become invalid. Put the link on the heading and stretch its hit area with a ::after pseudo-element positioned over the card.
• Logout and other state changes. Logging out changes server state, so a form POST behind a button is more correct than a GET link. Prefetchers and crawlers can follow links without a human clicking.

• SEO and crawlability. Crawlers follow <a href>. They don’t click buttons or run click handlers, so navigation hidden behind router.push() on a button is invisible to search engines and link-preview bots.
• Browser features users expect. Links get middle-click, Cmd/Ctrl-click, drag-to-bookmark, copy link address, hover URL preview, :visited and Back. Fake links lose all of it, and users feel it even if they can’t name it.
• HTTP semantics and security. Links issue GET requests, which must be safe and repeatable. Anything that changes data belongs behind a button and a POST/PUT/PATCH/DELETE. A “Delete” link can be triggered by a prefetcher, a browser extension or a malicious <img src> (a CSRF vector) without anyone clicking.
• Performance. <NuxtLink> and <RouterLink> prefetch route chunks when they enter the viewport or on hover. A button calling router.push() gets none of that, so the navigation feels slower.
• Analytics. Name events by intent (signup_started), not by element (button_click), so swapping a button for a link doesn’t break dashboards.
• Testing. Query by role in tests (getByRole('link', { name: 'Reports' }) in Testing Library, Playwright or Vitest browser mode). If the test can’t find it by role, neither can a screen reader. This turns semantics into something CI enforces.

The component picks the element from its props: to means a router link, href means a plain link, and neither means a button.

<script setup lang="ts">
import { computed } from 'vue'
import type { RouteLocationRaw } from 'vue-router'
import { NuxtLink } from '#components'

const props = withDefaults(defineProps<{
  to?: RouteLocationRaw
  href?: string
  type?: 'button' | 'submit' | 'reset'
  variant?: 'primary' | 'secondary' | 'ghost'
}>(), { type: 'button', variant: 'primary' })

const isButton = computed(() => !props.to && !props.href)
const tag = computed(() => props.to ? NuxtLink : props.href ? 'a' : 'button')
</script>

<template>
  <component
    :is="tag"
    :to="to"
    :href="href"
    :type="isButton ? type : undefined"
    :class="['btn', `btn--${variant}`]"
  >
    <slot />
  </component>
</template>

Rules that keep it honest:

• Default type to "button". Never inherit the browser’s submit default by accident.
• Only pass button-only attributes to buttons. type, disabled, aria-pressed and aria-expanded are invalid or meaningless on <a>.
• No disabled links. A link that goes nowhere shouldn’t be a link. Render text, or a button with aria-disabled.
• Make icon-only usage require a label. Use a TypeScript discriminated union so iconOnly: true without label: string fails to compile.
• One set of styles for both elements, including :focus-visible, :hover and a reset for the link underline, so styling never drives element choice.
• Document the decision rule in the component’s docs page, with the “new tab” test, so consumers pick to/href vs @click correctly.
• Lint for it. eslint-plugin-vuejs-accessibility flags clickable non-interactive elements and missing labels. Add role-based component tests (see the testing note above).