Give a Background Image Link a Name Readers Can Use

A clickable card can look complete while its HTML provides no useful name for the link. If the entire message is carried by a CSS background image, do not assume that people using assistive technology receive the same information. Put meaningful text in the link and treat the background artwork as decoration around that text.

Imagine Bea building a small community reading site on Cloudflare Pages. One large card uses a photograph of books to lead to a reading guide. Sighted visitors may guess what it means, but the link itself is empty. Bea needs to check what the page communicates beyond the photograph, not simply whether clicking the card reaches the right address.

Inspect the link beneath the picture

Here is the simplified starting point. The class supplies the card's appearance, including a background image and enough height to make it visible. The destination is a local example path, not a complete page supplied by this snippet.

<a href="/reading-guide/" class="guide-card"></a>

The element has a destination, but there is no text between its opening and closing tags. In this example there is also no other naming mechanism. A reader should not have to infer the card's purpose from the filename, surrounding decoration, or the browser's treatment of an unnamed link.

MDN notes that browsers do not provide special information about CSS background images to assistive technology. That makes the image a poor place to store the only explanation of an interactive element. Its visual presence does not establish that the link has a meaningful accessible name.

Bea asks two separate questions while inspecting the card: “Where does it go?” and “What is it called?” The destination answers the first. The words available to identify the link answer the second. A working address does not excuse an absent or misleading name.

Add words that describe the destination

For this card, a simple repair is to put visible text inside the native link. W3C's naming guidance favors visible text when it can provide a suitable accessible name. That approach also helps visitors who can see the photograph but do not know what action it represents.

<a href="/reading-guide/" class="guide-card">
  Reading guide
</a>

The picture can remain in the card's styling, but it no longer carries the whole explanation. “Reading guide” identifies the intended destination directly. Bea does not need to invent a separate invisible phrase when the visible wording already does the job in this straightforward example.

She also checks that the text remains visible in the final design. Adding useful words and then hiding them with a styling trick would not achieve the same result for people reading the screen. The repair should survive the transition from an HTML example to the actual page layout.

Check the label at the narrowest layout the site supports. If the card becomes smaller, its words should not disappear behind cropping or overlap nearby content. A name that is present in the markup still needs a usable visual presentation.

Avoid vague labels such as “Open” when several cards lead to different resources. A page containing a reading guide, an event calendar, and a borrowing policy needs words that distinguish those destinations. The label should describe the resource accurately rather than sound impressive or encourage a click without context.

Keep the name and destination in agreement

Bea verifies that the guide card actually leads to the reading guide. A clear label attached to the wrong route is a different defect, but it can create the same practical confusion for the reader. Naming and navigation checks should therefore be recorded separately.

If the site's organization changes, review both properties together. Moving the guide into a new section may require an address change without requiring a new label. Replacing the guide with a registration form would require reconsidering what the link says, not merely changing its destination behind an unchanged card.

When looking for examples of public resources, a 사이트모음 can be a discovery reference, not evidence that a particular site's links are accessible or accurately named. Inspect the actual page and destination you plan to use. The source of a link does not replace checking its purpose in your own layout.

For Bea's handoff, the useful statement is specific: “The card is named Reading guide, and its destination was checked against the intended guide page.” That is stronger than saying the card looks right, while still avoiding a claim that the entire site has completed an accessibility review.

Test more than the visual appearance

Use the browser's accessibility inspection tools to examine the link's role and computed name. For the repaired example, the expected role is link and the expected name is “Reading guide.” This checks what the browser derives from the markup rather than what a reviewer assumes from the picture.

Next, move through the page with the keyboard. The link should be reachable, its focus should be visible, and activating it should lead to the intended destination. A meaningful name does not, by itself, prove that the focus treatment or navigation behavior is usable.

Also inspect the card when the background is absent. The visible words should still explain the route. This is a useful design check, not a claim that disabling an image reproduces every experience of someone using assistive technology. Different checks reveal different aspects of the same component.

Finally, test with the assistive technology relevant to your audience when possible. Browser inspection is valuable evidence, but it is not a substitute for every browser and screen-reader combination. Record which environment you tested and avoid describing one local result as universal coverage.

Keep the repair small and maintainable

A short component review can stop the problem from returning when someone changes the page's artwork. Bea uses five steps before approving the card for the next version of the site:

1. Locate the actual link element and check whether its purpose is expressed in text rather than only in background artwork.
2. Add concise visible wording inside the link when that design is suitable, keeping the native navigation element.
3. Confirm the computed role and name, then compare the wording with the resource at the destination.
4. Check keyboard focus, activation, and readability in the final layout, including a view without the decorative background.
5. Repeat the relevant checks after changing the card's wording, destination, or styling, and record any remaining limitation.

This routine is deliberately about one component. It does not establish that the reading guide itself is well structured or that every other control on the site is named. Bea can complete the card repair while keeping those other tasks visible in the review notes.

For future edits, she asks contributors to preserve the visible label unless the destination's purpose changes. Replacing the photograph should not require rewriting hidden naming text in another location. Keeping one clear source for the wording makes it easier to notice when the design and meaning drift apart.

Questions about picture-based navigation

Can a background image be decorative?

Yes. A background can support the design without supplying information the reader needs to identify the link. The important distinction is whether meaningful content exists independently of the artwork. In Bea's repaired card, the words explain the destination and the photograph adds atmosphere.

Should I add an aria-label to every link?

No. Begin with the element's existing text and its computed name. A separate label is not automatically an improvement when the visible wording already names the link appropriately. Extra naming instructions can create another value to maintain, so use them deliberately when the design actually needs them.

Does this make the whole page accessible?

No. It addresses one naming problem. Contrast, focus visibility, document structure, destination quality, and other interactions still require review. Keep the result precise: the link now has meaningful text and its name has been checked in the stated environment. Continue the remaining page checks before calling the broader task complete.