A prominent call to action can look like a button while taking someone to another page. A small text control can look like a link while changing a setting.
Visual treatment alone does not determine the appropriate HTML element. The more useful question is what happens when the user activates the control.
Choosing the element around that behavior gives browsers and assistive technologies a clearer description of the interaction. It also reduces the amount of custom behavior a development team must recreate.
Use links for destinations
A link points to a resource or location. W3C’s accessibility guidance recommends using a native HTML anchor with an href attribute.
Adding a link role to another element does not automatically provide standard browser behavior, such as navigation or link-specific context-menu actions. Those responsibilities remain with the author of the custom control.
For a pricing page, documentation page, or section of a long article, a real link expresses the destination directly.
This remains useful when the link receives prominent styling. A filled background, rounded corners, or a large label does not change its underlying role.
A design review should therefore ask where the control goes, rather than approving its semantics from a screenshot.
Use buttons for actions
Buttons trigger operations such as submitting information, toggling a setting, removing an item, or opening an interface component.
W3C’s button pattern describes activation with both Enter and Space. The control’s state and label should also communicate its function, particularly for toggles.
Consider a bookmark feature. “Read article” points to a destination. “Save article” changes something in the application. Their proximity on the page does not make them the same kind of control.
Action labels should describe the result clearly. “Apply filters” is more informative than “Go” when the operation changes the current list.
Set button types explicitly in forms
HTML buttons associated with a form can submit that form by default when the type is omitted or invalid. MDN recommends type=”button” for buttons that are not intended to submit.
That distinction matters for secondary actions placed inside forms. A control that shows a password or adds an optional field should not unexpectedly trigger submission.
A simple review rule is to inspect every button in a form and ask whether its type matches its responsibility. The main submit control and supporting controls should be distinguishable in the markup.
This small check can prevent surprising behavior that is difficult to spot during a mouse-only demonstration.
Review ambiguous calls to action
Some labels conceal the interaction. “Get started” could navigate to registration, open an onboarding panel, or create a resource immediately.
Resolve that ambiguity in the product specification. State the destination or action, then select the element and wording that express it.
For a search interface, the form submission button performs an action, while each result title points to a destination. For an account screen, a billing-history link navigates, while a notification toggle changes a preference.
These distinctions help designers and developers discuss behavior in shared terms.
Test what users can do with the control
Use the keyboard to reach and activate each control. Check its accessible name and whether its announced role matches the result.
For links, inspect whether a meaningful destination exists. For buttons, confirm that activation produces the intended action without accidental form submission.
Semantic HTML is valuable because it makes the page’s behavior explicit. The resulting interface is easier to operate, review, and maintain.
