The Complete Accessibility Guide to Links and Buttons: Naming, Distinguishability, Focus, Click Targets, and Error Prevention for a “UI You Can Press Without Hesitation” (WCAG 2.1 AA)
Overview Summary (Key Points First)
- Links and buttons are the “hands” of the web experience. If users can’t press them, no information or service can reach them.
- What matters most are ① correct use of links vs. buttons ② clear, understandable names (purpose is conveyed) ③ distinguishability not reliant on color alone ④ sufficient click/tap target size ⑤ visible focus ⑥ error prevention for destructive actions.
- Vague labels like “Click here,” “Details,” or “More” cause particular problems in screen reader link lists, voice input, and keyboard navigation.
- This article includes ready-to-use naming templates, good/bad examples, implementation samples (HTML/CSS), and a 5-minute smoke test.
Target Readers (Specific): UI/UX designers, frontend engineers, web editors, EC/booking service operators, government/public site staff, QA/testers, design system owners
Accessibility Level: Aiming for WCAG 2.1 AA compliance (related criteria: 2.4.4, 2.4.7, 1.4.1, 1.4.3, 1.4.11, 2.5.3, 4.1.2, etc.)
1. Introduction: Links and Buttons Are the “Language of Action”—Ambiguity Makes Users Lost
Even if page structure and navigation are well organized, the final action is always taken through “links” and “buttons.” In other words, links and buttons are the “hands” of the user experience. If they’re hard to understand, hard to press, or easy to press by mistake, accessibility is never complete.
Screen reader users often search via “link lists” or “button lists,” keyboard users move sequentially with the Tab key, and voice input users operate by speaking the visible labels aloud (“Tap ○○”). This means the names, distinguishability, and operability of links and buttons directly determine usability.
In this article, we carefully summarize practical design, implementation, and operational points for creating a UI that anyone can press without hesitation.
2. The Fundamental Rule: Correctly Choosing Between Links and Buttons (This Decides Half the Outcome)
2.1 Links (<a>) Are for “Navigation”
- Navigate to another page
- Jump to another section on the same page
- Open or download a file
- Actions that should be shareable as URLs (routing)
Examples:
- “View shipping details”
- “Go to Careers”
- “Open the PDF”
2.2 Buttons (<button>) Are for “Actions on the Spot”
- Submit
- Open/close (accordions, modals)
- Apply filters
- Actions such as play/pause, save, delete
Examples:
- “Save”
- “Search”
- “Open menu”
If this distinction breaks down, assistive technologies can misinterpret whether something is navigation or execution, and keyboard operation or state announcements become unstable. Even if the appearance is the same, choosing the correct semantic element is the top priority.
3. Creating “Understandable Names”: Links and Buttons Are Usable Only When Their Purpose Is Clear
3.1 Commonly Misused: Vague Labels
- “Click here”
- “Details”
- “More”
- “Confirm”
- “Submit” (submit what?)
These may be understandable visually in context, but their meaning disappears in link lists or button lists. When many identical labels appear, confusion increases for voice input and switch users as well.
3.2 Naming Template: Verb + Object (+ Condition if Needed)
- “View order details”
- “Change shipping address”
- “Download receipt”
- “Reset password”
- “Reset search conditions”
The correct answer is when what will happen is immediately clear.
3.3 Example: Improving “Details” in a Card List
Bad Example
- Ten buttons labeled “Details”
Good Example (Include the Object in the Label)
- “View Tanaka’s profile”
- “View details of Project A”
If visual constraints require a short label, you can keep the visible text short while strengthening the accessible name:
<a href="/profile/tanaka" aria-label="View Tanaka’s profile">Details</a>
However, if the visible label and the spoken name differ significantly, users may be confused (WCAG 2.5.3). Whenever possible, improving the visible label itself is the safest option.
4. Don’t Rely on Color Alone for Links: Distinguishability and Contrast Basics
4.1 The Problem with Color-Only Links
Users with color vision differences, low contrast environments, screen glare, or zoomed views may see links as plain text.
As a principle, links should combine color with other cues such as:
- Underlines
- Icons
- Bold text
Recommended example:
a {
text-decoration: underline;
text-underline-offset: 0.15em;
}
a:hover, a:focus-visible {
text-decoration-thickness: 3px;
}
4.2 Contrast (Text, Links, Non-Text)
- Normal text: 4.5:1 or higher
- Large text: 3:1 or higher
- Non-text elements (borders, icons, focus rings, etc.): 3:1 or higher
Even when using brand colors for links, ensure sufficient contrast with both body text and the background.
5. Visible Focus: Never Remove the Keyboard User’s “Current Location”
The more links and buttons a page has, the more critical focus visibility becomes. If focus isn’t visible, keyboard users can’t tell where they are, making the page effectively unusable.
Recommended example:
:focus-visible{
outline: 3px solid #FF9900;
outline-offset: 3px;
}
5.1 “Removing” Is the Worst Choice; “Styling” Is the Right One
Avoid outline: none;. Instead, adjust thickness, color, and offset to fit your design. Choose colors that remain visible even over images or gradients.
6. Click Targets and Error Prevention: Create Tappable Areas with Spacing
6.1 Target Size Guidelines
Especially for mobile users, eye-tracking users, or people with limited motor control, tappable area size is crucial.
As a guideline, ensure buttons have a 44px-equivalent clickable area.
.btn {
min-height: 44px;
padding: 0.6rem 1rem;
}
6.2 Don’t Limit Links to “Text Only”
Inline text links can work, but for card-based UIs, small click targets increase errors.
- If the entire card is clickable, ensure the focus ring appears around the entire card
- Cards with multiple mixed links require careful structure to avoid misclicks
7. Protecting Destructive Actions (Delete, Cancel, Submit): Accessibility Includes Recovery from Mistakes
Accessibility isn’t just about being able to press something—it’s also about being able to recover from mistakes. Destructive actions are especially risky under high cognitive load or when using assistive technologies.
7.1 Keep Destructive Buttons at a Distance
- When placing “Save” and “Delete” together, separate them physically and don’t rely on color alone
- Use clear labels (“Delete this address” instead of just “Delete”)
7.2 Use Thoughtful Two-Step Confirmation
- Clearly state what will be deleted
- Provide “Undo” if possible
- For confirmation modals, manage focus correctly (open → confirm/cancel → return focus)
7.3 Pair Disabled States with Reasons
Simply graying out a button leaves users wondering why it’s unavailable.
- “Required fields are incomplete”
- “You do not have permission”
Providing a textual reason is more user-friendly.
8. Icons, Text, and ARIA: Safe Implementation Patterns for Common UI
8.1 Icon-Only Buttons
<button type="button" aria-label="Close">
<img src="close.svg" alt="">
</button>
- Treat the image as decorative with
alt="" - Provide the button’s name via
aria-label
8.2 External Links and New Tabs: Preserve Predictability
Links that open in a new tab are more reassuring when announced in advance.
- Icon + text
- Or a screen-reader-friendly note
Example:
<a href="…" target="_blank" rel="noopener">
Careers (opens in a new tab)
</a>
Avoid overusing new tabs—only use them when there’s a clear reason.
8.3 CTAs (Primary Actions): One Hero per Screen Is Clearer
Too many buttons cause hesitation.
- One primary CTA, one or two secondary CTAs
- Labels as verb + object
- Visually separate destructive actions
9. The 5-Minute Smoke Test: Minimum Checklist for Links and Buttons
- Navigation is links, actions are buttons
- Vague labels like “Click here” or “Details” aren’t mass-produced
- Links aren’t distinguished by color alone
- Sufficient contrast for text, links, and focus
- Focus is always visible when tabbing with a keyboard
- Click targets aren’t too small (especially on mobile)
- Destructive actions have confirmation or recovery
- Icon buttons have appropriate names (
aria-label)
Passing these checks dramatically reduces “can’t press,” “don’t understand,” and “pressed by mistake” failures.
10. Value for Each Audience (Concrete Benefits)
- Screen reader users: Can find desired actions easily in link and button lists.
- Keyboard users: Visible focus and logical structure reduce mistakes and stabilize operation.
- Voice input users: Specific, matching labels make voice commands easier.
- Users with cognitive differences: Fewer ambiguous words and confirmations for destructive actions provide peace of mind.
- Older users & mobile users: Larger click targets reduce mis-taps and stress.
- Operations teams: Naming templates stabilize quality across updates and shorten reviews.
11. Accessibility Level Assessment (What This Article Achieves)
- Major WCAG 2.1 AA Criteria Addressed
- 2.4.4 Link Purpose (In Context): Eliminating vague labels, clarifying objects
- 2.4.7 Focus Visible: Ensuring visible focus indicators
- 1.4.1 Use of Color: Distinguishing links without color alone
- 1.4.3 Contrast (Minimum) / 1.4.11 Non-text Contrast: Visibility of text, icons, focus
- 2.5.3 Label in Name: Names operable via voice input
- 4.1.2 Name, Role, Value: Proper link/button semantics and icon button naming
Improving links and buttons not only supports AA compliance, but also directly improves completion rates, error rates, and support inquiries.
12. Conclusion: Being Pressable Is the Smallest Unit of Kindness
- Links navigate, buttons act—choose semantic elements correctly.
- Use “verb + object” labels so purpose is clear even in lists.
- Don’t rely on color alone; add underlines and other cues.
- Never remove focus visibility—make it bold and clear.
- Create click targets with spacing to reduce errors.
- Protect destructive actions with confirmation, recovery, and distance.
Links and buttons may be small components, but for users they are the very gateway to action.
By treating that gateway with a little extra care, you reduce hesitation and help more people move forward with confidence. May your UI become a place that anyone can press with ease.