Can customers tell where each link goes before opening it?

Define the promise a link makes

A customer should be able to decide whether a link is worth opening from its wording or from context that software can determine. This is the core of WCAG 2.2 success criterion 2.4.4, Link Purpose (In Context). It does not require every link to be a miniature sentence, and it does not mean a visual paragraph several cards away can rescue an unclear label. The practical editorial question is: what will the person find or do after following this specific link? On a product page, ‘Delivery and returns for this item’ gives a better promise than ‘More’. On a service page, ‘See appointment prices’ is clearer than ‘Click here’. If a link opens a downloadable file or starts an external process, say so when that fact affects the decision. Keep the language true to the destination. An attractive label that promises a price list but leads to a general contact form is still misleading.

Use genuine programmatic context carefully

Context can make a short link meaningful, but it has to be structurally related to the link. A card heading marked as a heading, a list item containing the link, or a sentence containing it may give a user a reliable relationship. A heading merely positioned above several independent cards is a weaker basis, especially when a screen reader lists links separately. For a repeated ‘Read more’ pattern, the safest editorial fix is usually to put the article or product name into the link itself. If a design uses hidden extra wording, inspect the final accessible name and make sure the visible label remains part of it, because speech-input users must be able to say what they see. Avoid stuffing every card with the same broad label, such as ‘Learn more about our services’. Distinct destinations need distinct cues. The standard’s exception for a purpose ambiguous to everyone is narrow; it is not a license to omit a known destination.

Audit high-risk link groups first

Start with a link inventory from the paths customers actually use: homepage promotions, product cards, help articles, checkout support, account settings and booking instructions. Record the visible text, accessible name, destination, nearby heading and whether the destination is internal, external or a file. Group repeated labels and compare their destinations. This exposes ‘Details’ links that lead variously to a product page, a policy, a PDF and a form. Such labels may look tidy in a design review but force customers to open each link to learn its purpose. Review the English and Traditional Chinese editions separately, because a precise English destination label can become an unspecific Chinese ‘詳情’ during localization. Also check the destination after redirects and language switching; the correct label is only useful if the link lands on the promised content. A small business can do this from a spreadsheet before any code change.

Rewrite around the destination and choice

Replace generic verbs with the object of the decision. ‘Check size guide for this jacket’ tells a shopper what information is available; ‘Request a repair quote’ tells a service customer what process begins. When several links share one card, make their jobs distinguishable: ‘View features’, ‘Check availability’ and ‘Compare warranty terms’ should go to corresponding destinations, not three anchors on the same page with little difference. Be concise without deleting essential nouns. The link can use the exact title of a resource if the title is useful, but a long title is not automatically informative if it is marketing copy. If the destination itself cannot fulfill a concrete promise, improve that destination or link to a more appropriate one. Avoid relying on a tooltip that appears only on hover or on a tiny icon whose meaning is known only to the team. The text should survive mobile wrapping, keyboard focus and translation.

Review a service comparison page

Imagine a repair business comparing three service routes: book a diagnosis, read what a standard repair includes, or ask about an unusual fault. Three identical ‘Start’ buttons hide the choice. The editor writes ‘Book a diagnosis appointment’, ‘Read the standard repair scope’ and ‘Ask about an unusual fault’. A customer looking for a price can now see that none promises a fixed quote; the page should either link to a genuine price explanation or say that a quote follows assessment. If the appointment link starts a third-party booking flow, explain that transition where it matters and verify that the booking page opens in the intended language. This example shows why link work is not simply a matter of expanding labels. The wording must match the business process, and the destination must support it. A screen-reader link list, a mobile view and a staff review of the final URL should all lead to the same interpretation.

Test names and destinations together

Use a keyboard to reach every link in reading order, and inspect the focus state so the user knows which one is active. Then use a screen reader’s links list: can a person distinguish the choices without reading the whole page again? Return to the full page and test whether any short link has a truly programmatic context. Check the accessible name in browser tools, particularly where an icon, image or hidden span is involved. Open each destination, including after redirects, and confirm its page title and content fulfill the link’s promise. Repeat on the Chinese page; a translated label must point to the corresponding Chinese destination when one exists. Test a PDF link as a file, not a generic webpage. Record mismatches as pairs of label and actual destination so that an editor can correct the wording or a developer can fix the URL. A passing automated check for a nonempty link name is useful but does not prove that the name is meaningful.

Keep links meaningful after edits

Link purpose can decay without a broken URL. A team may rename a product category, replace a PDF with an enquiry form, or merge two help pages while leaving the old anchor text in place. Add a link check to the content change process: whenever the destination or a card heading changes, inspect the visible label, accessible name, language version and actual page reached. The person editing copy should be able to see both the label and URL in the content system. If a redirect is introduced, test the final destination instead of assuming that an HTTP success means the promise is kept. Track ambiguous labels by template as well as by page, because one card component can repeat the same weakness across a catalogue. This is a maintenance task with a clear trigger, not a claim that every link needs a monthly rewrite.

Pay attention to links whose action changes the customer journey rather than merely opening information. ‘Continue’ might advance a form, submit a booking request, leave the merchant site or open payment. Make the immediate result understandable and use a button for an action that changes the current interface when that better reflects the control’s role. For linked images, inspect whether the image and its alternative text communicate the destination; an empty alt on the only content of a link may leave the link unnamed. Where a product card has both a linked image and a linked title to the same page, decide whether the duplicate stops are useful and name them consistently. None of these details can be settled by the word count of a label. The test is whether a customer using vision, keyboard navigation, speech input or a screen reader can choose the intended route before activating it.