Link & Button Check
If it looks clickable, it must work exactly as promised. Dead links and broken buttons are the fastest way to frustrate users and lose trust.
1 The Hook — Why This Matters
In 2022, an Auckland animal shelter ran a winter donation campaign. Their homepage featured a big red "Donate now" button. It looked perfect. It was centred, bold, and urgent. The only problem: it linked to a page that had been deleted two months earlier. Every click returned a 404 error.
The shelter raised 40% less than the previous winter. A volunteer discovered the broken link on day 18 of the campaign. One dead button cost thousands in donations and weeks of goodwill.
Links and buttons are promises. When they break, the promise breaks. Testing them is not optional.
2 The Rule — The One-Sentence Version
If it looks clickable, it must work exactly as promised.
A link is a contract. The label tells the user what will happen. The destination must match the label. A button that says "Download" must download. A link that says "Contact us" must lead to a working contact method. Anything else is a defect.
3 The Analogy — Think Of It Like...
Door handles.
If a handle looks like you can pull it, but you must push, it is broken. The design promised one thing and delivered another. Links and buttons are the same. A blue underlined word promises a destination. A rounded rectangle promises an action. If the promise is broken, the user is stuck.
Senior engineer insight
The real skill in link and button checking is knowing that a 200 OK response is not the same as a working link — I learned that the hard way on a Wellington city council migration where every internal link returned 200 but silently redirected to the homepage due to a misconfigured Nginx rule. From that point on I always verify that the destination content matches the link label, not just that the server responded. At the Grad level, the shift is from "did it click?" to "did it deliver what the label promised?"
The most common mistake Grad testers make is treating a successful page load as a passing test — without checking that the loaded page is actually the correct destination.
From the field
During a broken-link audit for a NZ district council website ahead of a LGNZ digital accessibility review, the team assumed automated link checker results were comprehensive — the tool reported 98% of links healthy. What it missed entirely was a suite of "Report a problem" buttons wired to a deprecated form endpoint that returned HTTP 200 with an empty JSON body instead of an error. Citizens submitting pothole reports, noise complaints, and resource consent queries were getting a silent success screen while nothing reached the council inbox. The council had no idea for four months because the button didn't break visually. We added a response-body assertion to every form submission test after that, and now the council's test plan explicitly separates "link resolves" from "action completes".
4 Watch Me Do It — Step by Step
Here is a real NZ example: testing a small business website before launch. Follow these steps on every page you test.
Scenario: You are reviewing a Queenstown tour operator's site. The owner says "everything works." You verify.
- Hover over every link Check that the cursor changes and the destination URL appears in the browser corner. Look for unexpected redirects.
- Click every link Navigation, footer, body text, social icons, logos. Every single one. Note any 404s, timeouts, or wrong destinations.
- Test button lifecycle states Check default, hover, active (click), disabled, and loading states. A button that looks the same when disabled is a usability bug.
- Test keyboard activation Tab to every link and button. Press Enter or Space. If it only works with a mouse, it is an accessibility defect.
- Check for orphan buttons Orphan buttons do nothing when clicked. They look clickable but have no attached action. Click every button to confirm it responds.
- Test mobile touch targets On a phone, try tapping small links and buttons. If they are too close together or too small, users will mis-tap.
-
Check special link formats
mailto:links should open an email client.tel:links should trigger a phone call. In NZ, tel: links with spaces or dashes (liketel:0800 100 123) often fail. Usetel:+64800100123instead.
| Element | Test | Result |
|---|---|---|
| "Book now" button | Click, check destination | Pass |
| "Donate" button | Click, check 404 | Fail — 404 |
| Phone link | tel:0800 100 123 | Fail — dashes break it |
| Facebook icon | Click, check URL | Fail — old page URL |
| Disabled "Sold out" button | Visual state + no action | Pass |
Three defects in seven checks. The owner thought "everything works" because the main navigation loaded. They never tested the donate button, the phone link, or the social icons.
Scenario 2: Network-dependent link failure reveals environment issues.
A site works perfectly on your desktop. But when you test on a different network (mobile hotspot, offline mode), external links to third-party services fail silently. The app assumes the internet connection is always available.
| Link | Works Online | Works Offline / Slow Network | Issue |
|---|---|---|---|
| Internal page link | Yes | Yes | No issue |
| External partner API | Yes | Hangs 20s, times out | No timeout handling |
| Embedded map | Yes | Blank / error not shown | No error message |
| Analytics tracker | Yes | Hangs entire page | Blocking script |
The lesson: test links on different networks. An external CDN link might fail on a slow 3G connection while your local WiFi works fine. Users in rural NZ on slower networks will experience failures you never see.
5 When to Use It / When NOT to Use It
✅ Do it when...
- A new page or site is ready for review
- Navigation, footer, or contact details changed
- Social media or partner links were updated
- You are doing a pre-release sanity check
❌ Skip it when...
- You are testing back-end APIs with no UI
- The build changed only CSS colours
- You already ran an automated link checker and reviewed its results
Before you apply this technique, ask:
- Does your app have external links, social media icons, or partner integrations?
- Are you testing an internal API or a public website with clickable elements?
- Do you have access to real devices for testing tel: and mailto: links?
- Is network connectivity an issue (users on slow/offline connections)?
6 Common Mistakes — Don't Do This
🚫 Only testing happy-path links
I used to think: If the main navigation works, the links are fine.
Actually: Footer links, social icons, email signatures, and PDF downloads break far more often than main nav. Users discover broken links in the places you forgot to check. Test every clickable element, not just the obvious ones.
🚫 Not checking mailto: and tel: links
I used to think: mailto: and tel: links are simple; they always work.
Actually: mailto: links with missing subject lines, tel: links with spaces or dashes, and tel: links without the +64 country code all fail on some devices. In NZ, tel:0800 100 123 breaks on iOS. Always test special link formats on real devices.
🚫 Ignoring the back button
I used to think: The browser back button is the browser's problem.
Actually: Single-page apps and modal dialogs often break the back button. A user clicks "Open map", hits back, and lands on a different site. If your button changes browser history, test that back works as expected.
🚫 Assuming external links work offline
I used to think: Links to external sites are tested by those sites, not me.
Actually: When your site links to a third-party API, payment processor, or external resource, network failures on your connection affect the user experience. Test links on slow networks (3G) and offline. Add error handling so timeouts are visible, not silent failures.
When this technique fails
Link and button checking fails when you test only on a fast, reliable network. External links that work on desktop WiFi will fail on mobile 3G or in areas with poor connectivity. Also fails if you check only happy-path links (main navigation) and skip secondary links (footer, social icons, mailto: links). Test every clickable element and test on different networks.
7 Now You Try — Interview Warm-Up
Scenario: You are testing a Dunedin café website. Spot the link and button defects in this list:
- "Menu" link in navigation — goes to /menu
- "Book a table" button — goes to /bookings (404)
- Phone number:
tel:0800 100 099 - Instagram icon — links to instagram.com/oldcafehandle
- "Get directions" button — opens Google Maps correctly
Write down every defect before revealing the answer.
Defects found:
| # | Defect | Why it fails |
|---|---|---|
| 1 | "Book a table" 404 | Link points to deleted page |
| 2 | tel:0800 100 099 | Spaces break tel: on iOS; use +64800100099 |
| 3 | Instagram old handle | Social link points to rebranded account |
Tip: The "Menu" and "Get directions" links work. Three out of five clickable elements are broken. That is a 60% failure rate the owner never noticed.
Why teams fail here
- Treating a 200 HTTP status as proof the link works — silent redirects to homepages and soft 404s fool both humans and automated tools
- Running link checks only at release — partner URLs, social handles, and government portal paths change between releases and break without any code change on your side
- Scoping checks to the main navigation only — footer links, in-body citations, PDF download buttons, and email signature links are the highest-failure zones in NZ government and council sites
- Skipping mobile and real-device verification for tel: and mailto: links — a link that works on desktop Chrome can silently fail on an iPhone due to tel: formatting or a missing default mail client
Key takeaway
A link or button is not tested until you have confirmed that the destination matches the promise — not just that the server answered.
8 Self-Check — Can You Actually Do This?
Click each question to reveal the answer. If you got all three, you're ready to practice.
Interview Questions
What NZ hiring managers ask about Link & Button Check at the Grad level.
Q1. What would you check when testing a set of navigation links on a webpage?
Strong answer: Each link destination (does it go to the correct page?), link text (is it descriptive and meaningful out of context — "click here" fails WCAG 2.4.4?), external links (do they open in a new tab with appropriate warning?), broken links (HTTP 404 responses), hover and focus states (are they visible for keyboard users?), active/current state (is the current page's link styled differently?), and mobile tap target size (at least 44x44px recommended by WCAG 2.5.8).
Q2. You find a button that does nothing when clicked. How do you investigate and report this bug?
Strong answer: I check whether the issue is consistent (every click, or intermittent?), across browsers, and whether it appears in the browser console as a JavaScript error. I check the Network tab for a failed API call. I test with different user accounts in case it is a permissions issue. I report: the exact URL and button label, the expected behaviour, the actual behaviour, steps to reproduce, browser/OS, screenshot/recording, and any console errors. "Button does nothing" is more actionable with error messages attached.
Q3. What is the difference between a 404 error and a 500 error?
Strong answer: A 404 (Not Found) means the server received the request but could not find the requested resource — typically a missing page or deleted file. It is usually a content or configuration problem. A 500 (Internal Server Error) means the server encountered an unexpected condition — a bug in the application code, a database failure, or an unhandled exception. A 404 is expected for genuinely missing content; a 500 is always a bug. Both need to be reported, but 500 errors are higher severity.
Q1. Why do tel: links with spaces fail on some phones?
Not all devices parse spaces in tel: URLs. iOS in particular struggles with tel:0800 100 123. Use the international format without spaces: tel:+64800100123. Test on a real device, not just desktop hover.
Q2. What is an orphan button?
A button that looks clickable but does nothing. It may have been styled before the JavaScript was attached, or the click handler was removed. Click every button to confirm it responds. If nothing happens, it is a defect.
Q3. Should you test the back button after clicking a link?
Yes, when the link changes browser history. Single-page apps and modal dialogs often hijack the back button. A user should be able to return to where they started. If back sends them somewhere unexpected, it is a defect.