ACCESSIBILITY ≠ OVERLAY · 37
Accessible links: knowing where you are going before you click
📅 10 November 2026 · ⏱ 7 min read
A link should support a decision rather than require guesswork. Its text, context and behaviour determine whether people can navigate using a screen reader, keyboard, voice control or magnification.
01. When every destination is called “here”
Imagine a services page with eight links labelled “more information”. Seeing the whole page, you might associate each link with its surrounding card. Someone listening to a list of links, however, may hear eight identical names. They must return to the content, locate each block and reconstruct its relationship with the destination. A simple operation becomes an unnecessary search.
This affects more than blind visitors. Someone using magnification may see only a small portion of the card; keyboard users must decide whether each stop matters. Descriptive links reduce effort before activation. The useful question is what a person can anticipate from the information actually available to them, rather than what the designer understands from the complete layout.
02. Describe the purpose rather than an empty instruction
“Check service opening hours” provides a clearer expectation than “click here”. “Download the registration guide” explains more than “download”. A link does not need to become an endless sentence: select the words that distinguish the resource and avoid repeating the entire paragraph.
Its label must match the destination. If “Service prices” opens a promotional homepage without prices, the wording does not complete the task. Review links after replacing documents or reorganising pages. A previously accurate label can become misleading even while the URL continues to work. Editorial precision belongs to accessibility and routine maintenance. Assign responsibility for reviewing labels alongside destination changes, rather than treating them as permanently correct once published.
03. Valid context and understanding without context
WCAG 2.2 distinguishes understanding a link within its context from the stricter expectation of understanding it from its name alone. Level A criterion 2.4.4 allows link text together with context that software can determine. A related paragraph, list item or table cell can supply relevant information.
Consequently, “read more” is not automatically a failure in every situation. Examine the actual association, rather than visual proximity alone. Even where context satisfies the criterion, a specific name often makes link lists and quick exploration easier. Separate conformance assessment from the choice to provide a clearer experience. Do not turn a helpful recommendation into an invented rule, or assume that an attractive card automatically establishes a programmatic relationship.
04. Visible and announced names should agree
A link’s accessible name can come from text, an image or a mechanism such as aria-label. If its visible label says “Contact” but the accessible name is entirely different, someone using voice control may struggle to activate it by speaking what they see. Criterion 2.5.3 requires the name to contain the visible label text where applicable.
Improving visible wording for everyone is usually the first option. Avoid adding lengthy hidden descriptions to every link without reviewing the resulting name. The title attribute should not be the only place explaining the destination either: access to it differs between devices. Inspect the calculated name and listen to how it is announced in the actual interface, including any repeated or unexpected wording.
05. Linked images also need a purpose
If an image is the only content of a link, its text alternative should communicate the link’s function. A logo leading to the homepage needs to identify that navigation, rather than describe every curve of the artwork. A linked magnifying-glass icon should not end up named after a file such as “final-icon-2.svg”.
When image and text share one link and the text already explains its purpose, a decorative image can have an empty alternative to prevent repetition. Also review cards with an image, title and button leading to the same resource. Multiple consecutive links may create redundant stops. Seek a coherent solution without nesting links or stripping a whole container of its semantics and native interaction.
06. Links and buttons have different jobs
A link navigates to a resource or location. A button performs an action, such as opening a panel or submitting a form. They may look similar, but behaviour and expectations differ. Use native elements suited to the function; a link without a genuine destination is not a general solution for every control.
Do not replace that foundation with a div carrying a click handler and an improvised role. Focus, keyboard activation and other behaviours already provided by the native element would then need implementation. Confirm that links work with Enter and buttons respond according to their expected interaction. The chosen technology should support the task rather than make people discover a different behaviour in every component.
07. Make downloads and context changes predictable
When a link leads to a document, identify its subject clearly. Including the format and, where useful, file size helps people decide whether to open it on a phone or limited connection. “Registration guide, PDF” offers more information than a long address or unexplained icon.
Avoid opening new tabs simply out of habit. Where there is a reason, warning people about the behaviour helps preserve orientation. Distinguish that good practice from claiming that every new tab automatically fails WCAG. A clear label also does not make the destination file accessible. An unstructured PDF still presents barriers even with a perfect link name. Review the whole journey from choosing the resource through to consulting its contents.
08. Visibility, focus and room to activate
Links within paragraphs should be identifiable without relying on colour alone; underlining is often a clear, stable solution. Check contrast and ensure visited or focused states do not make text unreadable. People should recognise the interaction before hovering over it with a mouse.
Navigate using Tab and Shift+Tab. The focus indicator should be visible, and a component receiving focus must not be entirely hidden by author-created content; WCAG 2.2 addresses that particular situation in 2.4.11. Also examine spacing and applicable target-size requirements, taking their exceptions into account. Enlarging a clickable area must not produce overlaps that activate another destination accidentally. Check narrow layouts and magnification rather than assuming desktop spacing remains adequate.
09. Test the decision before testing the click
Choose a real task: finding opening hours or reaching support contact details. Read the link names without activating anything and note the destination you expect. Then follow the journey and compare expectations with the result. Repeat using a screen reader, a link list, keyboard and magnification as appropriate.
Automated tools can find certain missing names or contrast problems, but cannot decide whether “more information” promises the correct resource or whether a translation retains its meaning. Document ambiguity with location, announced name and expected destination. Do not assess a whole website from one isolated link. Review navigation, cards, footers and editorial content, which commonly originate from different components and publishing decisions.
10. Fix the source and keep published links clear
In WordPress and Divi, inspect both the editor’s wording and the resulting HTML and accessible name. Correct the shared module when many cards repeat a problem. Translate names and verify that destinations use the appropriate language: a localised label helps little if the target unexpectedly switches language.
An overlay does not independently know the editorial intention of every link and cannot guarantee that generic wording describes the right resource. Presentation controls may complement the work, but cannot replace that decision. Add a simple question to review: can someone make an informed choice before activation? Accessibility improves when people know where they are going, reach the expected content and can continue independently.

