Empty Links and Buttons: The Metric Your Scanner Counts and Your Audit Ignores

A screen reader user tabs through your homepage and hears it: link, link, link, button, link. No destinations, no labels, no clue where any of them go. The page looks finished. The icons are crisp, the social row is tidy, the cart button is exactly where it should be. Every one of those controls is unnamed, and the audit that was supposed to catch it counted low contrast text instead.

The number your audit buries

The WebAIM Million 2026 report scanned the home pages of the top one million websites in February 2026 and found detectable WCAG 2 failures on 95.9 percent of them, up from 94.8 percent in 2025, the first reversal after six years of small improvements. The average page carried 56.1 errors, a total of 56,114,377, up 10.1 percent on the year before. Six error types account for 96 percent of all detected issues, and they have been the same six for seven consecutive years. Low contrast text leads at 83.9 percent. Missing alternative text is second at 53.1 percent. Missing form input labels are third at 51 percent. Empty links are fourth at 46.3 percent, and empty buttons fifth at 30.6 percent. Missing document language is sixth at 13.5 percent. The empty link number is the one that should embarrass the industry most, because it is not a hard problem. A link with no accessible name is a one line fix, and nearly half the web ships it anyway.

The failure pattern is almost always the same. An anchor wraps an image with no alt text, or an icon font with no label, or nothing at all. A social media icon row is the classic case: five links, five icons, zero names. A cart icon with a badge count and no label is another. The link works with a mouse, so the person who built it never notices, and the person who tests it with a mouse never notices either. The scanner notices, and then the report buries the count under the low contrast total, because low contrast produces 34 distinct instances per page and empty links produce a handful. The metric that matters is not errors per page. It is named controls per page, and on that metric nearly half the web fails.

What the criteria actually require

WCAG 2.4.4, Link Purpose in context, Level A, requires that the purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined context. A link announced as link, with nothing after it, fails it outright. WCAG 4.1.2, Name, Role, Value, Level A, requires every user interface component to have a name that assistive technology can read, and an unnamed link has no name. Both are Level A, the most basic level of the standard, which means this is not an edge case or an advanced technique. It is the floor. The fix is one of three things, and all three take seconds: an aria-label on the link, a visually hidden text node inside it, or alt text on the image it wraps. The trap is the aria-label one. The site already has a post on this: when aria-label coverage hits one hundred percent, that is the warning sign, because it usually means labels are being sprayed over problems that should be fixed in the markup. Use a real text node or real alt text first, and reach for aria-label only when the visual design genuinely cannot carry the words.

The measurement that works is a count, not a percentage. Count unnamed links and unnamed buttons per template, not per page, because the same header ships the same empty social links to every page on the site. One broken header is a thousand broken pages, and the per page average hides that. Fix the template, then re-scan, and the number should drop to zero in one deploy. If it does not drop to zero, the links are being generated somewhere you have not looked: a plugin, a theme partial, a third party widget. Find the generator, not the instances.

The test that takes ten minutes

Open your homepage, turn off images, and tab through it. Every link and button you reach should announce a name that tells you where it goes or what it does. If you hear link with nothing after it, you have found one. Run the same test on the checkout, because the cart icon and the account icon live there too, and they are the two unnamed controls that cost the most. Then add the count to your deploy gate: zero unnamed links, zero unnamed buttons, or the deploy does not ship. It is the cheapest gate in accessibility, and it catches the failure that nearly half the web still ships.

Keep reading: Contrast Ratio Pass Rate: The Metric That Hides the Real Failures, Alt text coverage is lying to you: count decisions, not images, ARIA label coverage: when one hundred percent is the warning sign.

Frequently asked questions

What is an empty link?

A link with no accessible name: an anchor that contains only an image with no alt text, an icon font with no label, or an empty href with no text at all. A screen reader announces it as link, with nothing after it, and the user has no idea where it goes.

Which WCAG criteria do empty links fail?

WCAG 2.4.4 Link Purpose, in context, Level A, because the purpose of the link cannot be determined from its text or context. They also fail 4.1.2 Name, Role, Value, because the control has no name. Both are Level A, the most basic level.

How common are empty links really?

The WebAIM Million 2026 report found empty links on 46.3 percent of the top one million home pages, and empty buttons on 30.6 percent. Low contrast text is the only error type more common. The six most common error types account for 96 percent of all detected issues, and empty links are fourth on that list.

Why do empty links keep shipping if the fix is so small?

Because the failure is invisible to the people who ship it. An icon link looks finished on screen, and automated scanners that only count errors per page bury it under the low contrast count. The fix is one line: an aria-label, a visually hidden text node, or alt text on the image inside the link. Nobody files a ticket for a one line fix that nobody can see.