When Images Become Digital Dead Ends: The Link-Image Accessibility Trap

I've been staring at this accessibility audit report for the past hour, and it's a perfect example of how we keep making the same fundamental mistakes. Nine accessibility violations on a single page, and most of them stem from one incredibly common pattern: images inside links with no alternative text.
The page in question shows what happens when developers treat icons as purely decorative elements, forgetting that for many users, these images are the primary—or only—way to understand what a link does. Three separate image links (home, Twitter, LinkedIn) are completely inaccessible to screen reader users because they lack any form of alternative text.
The Screen Reader Experience
When a screen reader encounters these broken links, users hear something like "link, graphic" or just "link" with no indication of where it leads. Imagine trying to navigate a website where every button is labeled "button" and every link is labeled "link." That's the experience we're creating for blind and visually impaired users.
Research from our accessibility testing analysis shows that these basic image alternative text failures represent some of the most persistent barriers on the web. Despite being covered by the most fundamental WCAG success criteria—1.1.1 Non-text Content (opens in new window) and 4.1.2 Name, Role, Value (opens in new window)—image-only links continue to proliferate.
Two Approaches, Same Goal
The audit mentions HAL (presumably an automated testing tool) offering two solutions for these image-only links: adding alt text to the image or adding aria-label to the link. Both approaches work, but they serve slightly different purposes.
Option 1: Alt text on the image
<a href="/home">
<img src="home-icon.svg" alt="Home page">
</a>
Option 2: Aria-label on the link
<a href="/home" aria-label="Go to home page">
<img src="home-icon.svg" alt="" role="presentation">
</a>
I typically recommend the second approach for icon-only links because it gives you more control over the announced text and makes the decorative nature of the icon explicit. The aria-label becomes the accessible name for the entire link, while the empty alt attribute with role="presentation" tells assistive technology to skip the image entirely.
Beyond the Technical Fix
What strikes me about this audit is how it reveals a deeper organizational capacity issue. These aren't complex accessibility requirements—they're foundational web development practices that should be caught in any basic code review. The fact that multiple image-only links made it to production suggests gaps in the development workflow itself.
The missing navigation landmarks (no <nav> or <header>) compound the problem. Screen reader users rely on these semantic markers to understand page structure and navigate efficiently. When you combine unlabeled links with missing landmarks, you've created a navigation nightmare.
The Context Problem
One detail that caught my attention: the audit shows an image with alt text reading "company-logo.png"—the filename instead of meaningful alternative text. This is actually worse than no alt text at all because it actively misleads users. A screen reader announcing "company logo dot P N G" provides zero useful information while taking up cognitive bandwidth.
This pattern suggests developers who know they should add alt text but don't understand its purpose. It's a perfect example of what we see in accessibility implementation research—surface-level compliance that misses the underlying user need.
Systematic Solutions
For development teams dealing with similar issues, I recommend building accessibility checks directly into your workflow:
Automated Testing Integration Tools like axe-core can catch missing alt attributes during development. Set up your CI/CD pipeline to fail builds when images lack alternative text.
Code Review Checklists Include accessibility criteria in your pull request templates. Every image should have meaningful alt text or be explicitly marked as decorative.
Design System Standards Document alt text patterns for common UI elements. Icon buttons, logo images, and decorative graphics should have clear guidelines that designers and developers can follow consistently.
The Bigger Picture
These image-link failures represent more than technical debt—they're barriers to equal access. When we ship code with unlabeled links, we're essentially posting "No Screen Readers Allowed" signs on our digital properties.
The Pacific ADA Center's guidance on web accessibility (opens in new window) emphasizes that these basic barriers often have the most significant impact on users' ability to complete essential tasks. A home link that can't be identified prevents users from navigating back to your main page. Social media links without labels make it impossible to follow your organization on other platforms.
In my experience working with development teams, fixing these image-link issues becomes a catalyst for broader accessibility improvements. Teams that start by properly labeling their images often discover they need better semantic HTML, improved keyboard navigation, and more thoughtful color contrast choices.
The technical fixes are straightforward—meaningful alt text, proper ARIA labels, semantic landmarks. The harder work is building organizational processes that prevent these barriers from appearing in the first place. But when we get both right, we create digital experiences that work for everyone.
About Marcus
Seattle-area accessibility consultant specializing in digital accessibility and web development. Former software engineer turned advocate for inclusive tech.
Specialization: Digital accessibility, WCAG, web development
View all articles by Marcus →Transparency Disclosure
This article was created using AI-assisted analysis with human editorial oversight. We believe in radical transparency about our use of artificial intelligence.