Select buttons and links based on function rather than appearance.
Links navigate to a destination, buttons trigger an action. The visual design must not replace this functional separation.
For web developers and UX teams, "semantically selecting buttons and links" can be assessed primarily based on two points: "navigation destination" and "link as a switch." This comparison makes the functional boundary tangible.
Published: 3 min read · Author: Sebastian Geier
When is a button and when is a link the semantically correct control element?
A link leads to a different URL or location, while a button changes the current state or triggers an action. The native element is chosen according to this sequence and designed independently so that keyboard, browser, and assistive technology behavior remains predictable.
Navigation Destination
Navigation Destination – Switching to a URL, document anchor, or external resource is implemented with a true link.
Action Performed – A state change, form action, or interface control uses a button with appropriate default behavior.
Expected Operation – Element type, accessible name, focus state, and keyboard trigger correspond to the same recognizable function.
Action Performed
For each interactive element, clearly describe the activation sequence as a change of location or state action.
Use the appropriate native link or button and completely decouple styling from the selected HTML element.
Practically test click, enter, spacebar, context menu, and focus display according to the expected element behavior.
Practical Scenario: "Link as a Switch"
A map component uses a button with JavaScript to switch to the details page, while a link without an href opens the filter area. The roles are reversed: The map title becomes a true link, the filter opener a button with `aria-expanded`; both retain their previous visual design.
Link as a toggle
Link as a toggle – An `a` element without an `href` controls a state and does not behave as expected when typing, copying, or opening a new tab.
Button as navigation – JavaScript changes the URL via a button and removes browser features such as link preview or opening in a new window.
Appearance as semantics – Components are named according to color or shape and change their element type, even though their function remains the same.
Expected Operation
Percentage of inventoried interactions whose native element type matches the documented navigation or action sequence.
Number of custom click handlers on non-interactive elements or links and buttons with artificially recreated default behavior.
Which questions trigger further checks after "Semantically selecting buttons and links"
An in-depth question answered Clearly labeling PDFs, downloads, and external linksHow to clearly and accessibly label PDFs, downloads, and external links?
Further Perspectives Avoid JavaScript navigation without true links..
If you want to practically implement "Semantically selecting buttons and links," you can find more information on... Robust Website Systems Refer back to this. The focus there is on "Native Semantics and Page Structure" and "Navigation Target."
Conclusion: Choose buttons and links semantically
Links transport users to another location, while buttons change the current state or trigger an action. This functional boundary creates predictable behavior independent of the design.
Sources and Further Information
The following official documentation and standards provide the technical classification.
HTML Standard: Semantics – WHATWGPrimary specification for the semantic roles and structures of native HTML elements.
Headings – W3C Web Accessibility InitiativeOfficial implementation guide for heading ranks, content organization, and relationships to page regions.
ARIA in HTML — W3C RecommendationThe current W3C Recommendation defines which ARIA roles and attributes are permissible additions to HTML semantics and which redundant or contradictory uses should be avoided.
Key Thesis
A link is used to change location, while a button is used for a state change or action. The native element ensures predictable keyboard and assistive technology behavior.
What This Is Not About
This does not refer to simply ticking off a single checklist. The crucial factors are the separate risks of "Link as a switch," "Button as navigation," and "Visuals as semantics."
What it's about
Three requirements define the solution: "Navigation goal," "Executed action," and "Expected operation." They must be successfully combined in a productive environment.
Semantic HTML & Accessibility
Making focus states visible without distorting the design
"Semantically selecting buttons and links" includes the question, as a separate test step, of how to integrate clearly visible focus states into a design system.
Semantic HTML & Accessibility
Developing modal dialogs with clean focus management.
"Semantically selecting buttons and links" is supplemented by a separate decision: How does correct focus management work in a modal dialog?
Insights Overview
All VELUNO Insights at a Glance
Further analyses on Website Systems, digital visibility, and robust working models.
Executed action: next step
An interaction inventory should record the goal or state sequence of each clickable element. Deviations can then be corrected with native elements without redesigning the visual component system.