What is this?
An accessible name is the text that identifies a control to software rather than to the eye. Images, buttons, links, and form fields each need one. AccessKnight reads all four groups out of the raw HTML and scores them together at 10 points, the largest single check in the machine-readability score.
The four groups carry different weights: images 2 points, buttons 3, links 3, and form controls 2. Each group is scored as the ratio of named elements to total elements, multiplied by its weight and rounded. The link group is the strictest, because a link needs more than a name — its visible text must not be one of eleven generic strings the module treats as meaningless.
The mechanism is identical in both directions, which is why this rule sits in the Shared Core pillar. An icon-only button carries its meaning in SVG path data — vector geometry, not text. A screen reader builds an accessibility-tree node with the role button and an empty name, so it announces "button" and stops. An extraction model parsing the same HTML finds a button element whose only string is a CSS class. Neither one failed at reading. The name was never written down.
Who does this affect, and why does it matter?
Every engine that reads the page as markup. ChatGPT search retrieving through OAI-SearchBot, Perplexity, Claude, and Google AI Overviews all build their understanding of what a page offers from named elements. An unnamed control is a piece of your page that no retrieval system can describe, and a generic link is a path it cannot label.
And disabled users, for the identical reason. A screen reader user tabbing a checkout hears "button, button, button" and has to guess. A voice-control user says "click submit" and nothing happens, because there is no name to match against. This is the clearest case in the library where one edit serves a screen reader, a search crawler, and an answer engine at once — the WCAG rules img-alt, img-alt-interactive, img-alt-redundant, button-text, link-empty, link-text, form-labels, and select-label each cover a piece of what this single check measures.
AccessKnight scores this at 10 points, the largest single check in the 100-point score and the only Shared Core check rated serious. Nothing else in the scan is worth as much, and no other check touches as many elements: a typical page has dozens of links and images inside its scope.
Of the four sub-signals, links is the one worth naming plainly. A navigation full of "Learn more" and "View" reads as a set of unlabelled doors. Naming them is not a ranking tactic and does not promise any engine will quote you; it removes the ambiguity that makes a page hard to summarise, and it improves the odds that whatever does read the page can describe what is on it. The same edit clears the corresponding WCAG findings, which is the strongest argument in this library for doing the work once.
How do I fix it?
Work the four groups in turn: an alt attribute on every image, an aria-label on every icon-only button, visible link text that names its destination, and a real label element bound to every form control. The link group is the only one of the four whose fix changes visible words rather than markup, which makes it the one to plan for rather than leave until last.
- Give every img element an alt attribute. Describe what the image shows; use alt="" only when the image is genuinely decorative and its meaning is already in the surrounding text.
- Find every button whose content is an icon or an SVG and add an aria-label naming the action, then mark the icon itself aria-hidden="true" so it contributes nothing to the name.
- Rewrite link text that reads "click here", "read more", "learn more", "more", "view", "details", "here", "link", "this", "go", or "click" so the visible words name the destination. Adding an aria-label does not rescue generic visible text — this check reads what is on screen.
- Associate every input, select, and textarea with a label, either a label element whose for matches the control's id or a label wrapping the control. A placeholder is not a label and earns nothing.
- Check image buttons written as input type="image" separately — they fall outside both the button and the form-control groups in this check, so the WCAG button-text rule is what catches a missing alt on them.
- Re-scan with AccessKnight and confirm all four sub-signals report their full count in the finding detail.
<img src="/hero-2024-final-v3.png">
<button class="icon-btn" onclick="openCart()">
<svg viewBox="0 0 24 24" aria-hidden="true"><path d="M7 4h-2l-1 2..."/></svg>
</button>
<a href="/pricing">Learn more</a>
<input type="email" name="email" placeholder="Email address">
<!-- images have alt: 0/1; buttons named: 0/1;
links have descriptive text: 0/1; form controls labeled: 0/1 → 0 of 10 --><img src="/hero-2024-final-v3.png"
alt="Barista pouring a latte at the Northwind counter">
<button class="icon-btn" aria-label="Open cart (3 items)" onclick="openCart()">
<svg viewBox="0 0 24 24" aria-hidden="true" focusable="false"><path d="M7 4h-2l-1 2..."/></svg>
</button>
<a href="/pricing">See wholesale pricing</a>
<label for="email">Email address</label>
<input type="email" name="email" id="email" placeholder="you@company.com">
<!-- images have alt: 1/1; buttons named: 1/1;
links have descriptive text: 1/1; form controls labeled: 1/1 → 10 of 10 -->How does AccessKnight detect this?
AccessKnight scores four groups on the raw HTML and adds them together, capped at 10. Images are worth 2: every img element counts except those carrying aria-hidden="true" or role="presentation", and an image passes if it has an alt attribute at all — alt="" counts, because this check tests whether a name exists, not whether it is a good one. Buttons are worth 3 and cover button, [role=button], and input of type button, submit, or reset; a button is named by its text content, aria-label, aria-labelledby, title, or value. Links are worth 3 and cover every a[href]: the link must have a name from text, aria-label, title, or a child image with alt, and its trimmed lowercase text must not exactly match one of eleven generic strings — "click here", "click", "here", "read more", "more", "learn more", "link", "this", "go", "details", "view". The match is exact and it is made against the visible text, so "Read more about wholesale pricing" passes while "Read more" fails no matter what aria-label is attached to it. Form controls are worth 2 and cover select, textarea, and input except the hidden, submit, button, reset, and image types; a control is labelled by a matching label[for], an ancestor label, aria-label, aria-labelledby, or title, and a placeholder does not count. Each group scores its ratio times its weight, rounded, and the pass, warn, or fail status is taken from the mean of the four ratios at thresholds of 0.95 and 0.70. One consequence to read carefully: a group with no elements is treated as a perfect ratio, so a page with no images and no forms collects those 4 points for having nothing to check — a 10 of 10 on a sparse page is not the endorsement it looks like.
What strings mean this?
If one of these strings is in front of you right now — in a config file, an HTTP header, an AccessKnight report, or another checker’s output — it is describing the failure explained on this page.
- AccessKnight report
- “Accessible names on interactive elements”
- AccessKnight report
- “Give every control a name an agent can read: alt on images, text/aria-label on buttons, descriptive link text, and labels on form fields.”
- Lighthouse
- “Image elements do not have [alt] attributes”
- Lighthouse
- “Buttons do not have an accessible name”
- Lighthouse
- “Links do not have a discernible name”
- Lighthouse
- “Form elements do not have associated labels”
- axe DevTools
- “Links must have discernible text”
- WAVE
- “Empty button”
Frequently asked questions
I added an aria-label to my "Learn more" link and it still fails. Why?
Does alt text help AI search?
Which link text does AccessKnight treat as generic?
Does a placeholder count as a label?
My page has no images or forms and it scored 10 of 10. Is that right?
Where does this come from?
Every external claim on this page traces to one of the documents below — the vendors’ and standards bodies’ own documentation. What AccessKnight adds is the scan, not the standard.