How to fix: Decorative images inside interactive elements

An empty alt attribute (alt="") tells assistive technology to ignore an image because it is decorative. That is correct when the image sits next to text that already conveys the meaning. WCAG Success Criterion 1.1.1 Non-text Content covers the case where it backfires: when that empty-alt image is the entire content of a link or a button, hiding the image hides the control's name along with it.

Think of an icon-only link or button whose sole content is an <img> marked alt="". Sighted users see a recognizable glyph (a cart, a magnifying glass, an X to close a dialog) and understand the action. A screen reader, told to skip the image, reaches the control and finds nothing to announce, so it reports a bare "link" or "button" with no name. The fix is to restore a name: usually give the image meaningful alt text, which then becomes the control's accessible name, or keep the image decorative with alt="" and put the name on the parent via an aria-label, aria-labelledby, title, or visible text.

Screen reader users are blocked directly. An icon-only cart link, hamburger menu toggle, or modal close button that announces as an unnamed "link" or "button" gives them nothing to act on, and these are usually the high-traffic controls a user is actively trying to reach. When the unnamed control is a dialog's close button, the user can become trapped, unable to tell which control dismisses the overlay.

Voice-control users are affected too, since they activate a control by speaking its name ("click search"). With no accessible name there is nothing to say, so the control is effectively unreachable by voice even though it is perfectly visible on screen.

This is a Level A failure, the most basic conformance tier, and unnamed interactive elements sit alongside missing alt text and low contrast among the violation types plaintiff firms scan for first, because a control with no accessible name is trivial to detect at scale. WCAG 2.1 Level AA is the de-facto benchmark U.S. courts apply to ADA Title III claims, and naming interactive controls is foundational to it.

The business stakes are concrete because the affected elements drive conversions: the cart, the menu toggle, the search button, the close control on a checkout modal. Web accessibility lawsuits have climbed year over year and most target businesses under $25 million in revenue, so an unnamed primary control is both a usability dead end and a screenshot-ready audit finding, fixed with a single attribute.

1. Find links and buttons whose only content is an image marked alt="" (icon-only controls are the usual culprits).
2. Decide how to name the control. The simplest fix is to replace the empty alt with descriptive alt text, since the image's alt becomes the control's accessible name.
3. Write that name for the destination or action, not the picture: alt="View cart" or alt="Search", not alt="shopping bag icon".
4. If you would rather keep the image decorative, leave alt="" and instead add aria-label (or aria-labelledby, title, or visible text) to the parent link or button.
5. Confirm the control now exposes a name, then re-scan to verify the empty-alt-inside-interactive failure is cleared.

<a href="/cart"><img src="/cart.svg" alt=""></a>
<button><img src="/close.svg" alt=""></button>

<a href="/cart"><img src="/cart.svg" alt="View cart"></a>
<button aria-label="Close dialog"><img src="/close.svg" alt=""></button>

AccessKnight selects every image with an explicitly empty alt (img[alt="") and checks whether it sits inside an interactive ancestor: an <a>, a <button>, or an element with role="button". When such a parent exists, it reads the parent's accessible name from three sources, its trimmed text content, an aria-label, and a title, and flags the image only when all three are empty, meaning the control has no name at all. If the parent has visible text, an aria-label, or a title, it is not reported, because the empty-alt image is then correctly decorative within a control that is already named.