Start with what the control does
When a visitor activates a control, do they go somewhere, or does something happen where they are? That question usually settles the choice. A link takes someone to a destination, such as another page, a section of the current page, an email address or a file. A button performs an action, such as submitting a form, opening a menu or revealing more information.
The distinction is about behavior, not appearance. A link to a pricing page can be styled as a prominent rectangle. It is still a link. A quiet text control that expands an answer is still a button. Choosing the appropriate HTML element gives visitors familiar behavior and helps assistive technology describe what the control is. Styling alone cannot provide those benefits.
Use links for destinations
Use a link with a real destination when someone should be able to follow it, copy its address or open it in another tab. Site navigation, a “Read the guide” call to action and a table of contents all fit this pattern. A link to a section of the same page also counts as navigation, even though the visitor stays on that page.
If a control downloads a file, a link is generally the natural choice because the file is its destination. Set expectations in the label or nearby text: “Download the annual report (PDF)” tells visitors more than “Click here.” If a link opens a new tab, do so only for a reason and make that behavior clear. Unexpected changes of context can be disorienting.
Avoid using a link with no useful destination as a stand-in for a button. A link whose address is merely a placeholder may jump the page, fail without JavaScript or suggest that navigation is available when it is not. If activation changes an on-page state rather than taking the visitor to a destination, start with a button.
Use buttons for actions and state changes
Buttons suit tasks such as “Send message,” “Apply filters,” “Show menu” and “Close dialog.” They also suit controls that change an item without navigating, such as adding it to a comparison list. In a form, use a submit button for the action that sends the form. For a button inside a form that should not submit it, specify its type as button; otherwise, it may submit the form unintentionally.
An action needs a clear result. If a button opens a panel, make its label describe that action, and update any relevant expanded-state information when the panel changes. If submission takes time, provide understandable feedback rather than leaving the visitor to wonder whether activation worked. A disabled button can prevent activation, but it may also make the next step hard to discover. Where possible, explain what information is missing instead of relying on a disabled state alone.
Some interfaces blur the line. A client-side site might load a new view without a full page refresh, but if the visitor is going to a distinct destination with its own address, a link is usually the better fit. Decide from the visitor’s task, not from the code used to implement the transition.
Make both controls easy to recognize and use
Native links and buttons come with useful keyboard behavior. Links are normally activated with Enter; buttons can normally be activated with Enter or Space. Replacing either with a clickable generic element means recreating that behavior, along with focus handling and an appropriate role. For most small sites, using the native element is simpler and more dependable.
Give every control a name that makes sense in context. “View delivery options” is more helpful than several identical “Learn more” links on one page. An icon-only control needs an accessible name that identifies its action, such as “Open search.” Keep a visible focus indicator so keyboard users can tell where they are, and make controls large enough and spaced well enough to operate comfortably.
Visual design should offer clues without being the only source of meaning. Links in running text should be distinguishable from surrounding text, while buttons should look actionable. You can use a shared visual style for a prominent link and a button, but test whether their labels and placement still make their different outcomes clear.
Run a quick control audit
Pick one important page and list its interactive controls. For each one, finish this sentence: “Activating this will…” If the answer ends with a destination, check for a working link. If it describes an action or a change of state, check for a button. Then read the labels without the surrounding layout. Can you tell what each control will do?
Finally, move through the page using only a keyboard. Check that every control can receive focus, has a visible focus state and works as expected. Open any menus or dialogs, submit a test form if appropriate, and confirm that the result is understandable. This short review can catch misleading controls before they become a recurring problem across the site.
