Logo Alt Text: What to Write for SEO and Screen Readers

Open a small business site with a screen reader running and press Tab once. On a lot of sites the first thing you hear is something like "link, graphic, logo dash final dash v3 dash small dot p n g". That's the company's front door, read out as a file name somebody exported in 2019 and never thought about again.

WebAIM's 2026 Million report, published in March off a February crawl, found that 16.2% of home page images had no alternative text at all, an average of 10.8 missing per page. Of those, 45% were linked images, which leaves a link with nothing to announce. One in four linked images across the top million home pages is missing its alt text. Your header logo is almost always a linked image.

The fix is one attribute. What makes it awkward is that the correct value changes depending on where the logo sits, and most published advice hands you a single answer for every case. "Use your company name" is right maybe a third of the time.

Ask what the image is doing, not what it looks like

The W3C's alt decision tree, part of the WAI images tutorial, sorts images by job before it says anything about wording. If the image sits inside a link or a button, the guidance is to "use the alt attribute to communicate the destination of the link or action taken". If it's decorative, or if the same information already sits nearby as real text, "use an empty alt attribute". Only when the image carries meaning of its own do you describe it.

A logo is unusual because it can land in all three of those buckets on the same page. In the header it's a navigation control. In the footer it's usually a repeat of a company name that's already written out somewhere nearby. In a blog post about brand marks it's the thing the sentence is about. One file, and the right answer changes every time you move it.

That's also why the accessibility rule and the SEO instinct pull against each other here. Search engines read alt text as a description of image content. Assistive tech reads it as the accessible name of whatever the image is doing. When the image is a link, the second job wins, and no version of "put your keywords here" survives contact with it.

The header logo that links home

If the logo is the only thing inside the link, the link has no other text to fall back on. Give it an empty alt and you've built a link with no accessible name, which is a documented WCAG failure: F89, "Failure of Success Criteria 2.4.4, 2.4.9 and 4.1.2 due to not providing an accessible name for an image which is the only content in a link". A screen reader user tabbing through hears the URL, or nothing useful. And because it's the header, you've shipped it on every page of the site.

<a href="/">
  <img src="/img/acme.svg" alt="Acme">
</a>

Whether to add the word "home" is where the sources split, and both sides are defensible. The W3C's functional images page uses alt="W3C home" for exactly this pattern. WebAIM prefers the plain company name, alt="Acme Company", because a logo linking to the home page is such a common convention that spelling the destination out doesn't earn its keep. I lean WebAIM's way for a small business site, since the company name is also what someone hears when they pull up a list of links on the page, and "Acme home" reads oddly out of context. Neither choice fails anything, so pick one and use it everywhere.

There's a second header pattern that flips the answer. If the link wraps both the mark and the company name written as real HTML text, the image has become redundant:

<a href="/">
  <img src="/img/acme-icon.svg" alt="">
  <span>Acme</span>
</a>

The link already has an accessible name from the span. Give the image an alt value here and the screen reader says "Acme Acme". The W3C decorative images page shows the same structure with a crocus illustration sitting next to the words "Crocus bulbs", and uses alt="" on the picture.

One trap worth knowing about. If someone has put an aria-label on the <a> element, that label overrides everything inside it, including your alt text. Check for one before you spend an afternoon tuning an attribute nobody hears.

The footer logo, and other repeats

Footers usually carry a second copy of the mark, sometimes a mono or knockout version, sitting next to a copyright line that already spells out the company name. If that logo isn't a link, it's decorative. Empty alt. WCAG 1.1.1 says pure decoration should be "implemented in a way that it can be ignored by assistive technology", and an empty alt is how you say that in HTML.

If the footer logo does link somewhere, it's a control again and it needs a name. Same rule as the header, and people forget it constantly because the footer logo feels like decoration even when it isn't.

Partner and client grids are the case that trips teams up. Those marks are almost always links to the partner's own site, so the useful name is the partner's company name. "Partner logo" and "logo of Northwind" both waste the listener's time. If the grid isn't linked and there's a caption underneath carrying the same names, empty the images and let the captions do the work.

Context to alt text, in one table

Assume the company is Acme and the mark is an icon plus a wordmark.

Treat the third column as a rough guide. NVDA, JAWS, and VoiceOver each order and phrase the role differently, and users change their verbosity settings anyway. Don't write alt text that only makes sense if a particular screen reader says a particular word first.

Does the image contain words?

A wordmark is text rendered as a graphic. If the company name appears nowhere else nearby, that text has to survive in the alt value, or the information is simply gone for anyone who can't see the image. A pictorial mark or a lettermark carries no words, so the alt value has to say what the thing is instead. If you're not sure which of those you're holding, wordmark vs lettermark vs pictorial logo walks through the categories.

When you're writing about logos rather than using one to navigate, the description has to carry whatever the surrounding sentence depends on. A post about logo variations for light and dark backgrounds showing four versions of the same mark needs alt text that tells them apart. "Acme logo" four times gives a screen reader user nothing to compare.

Inline SVG has no alt attribute

Plenty of sites now ship the logo as inline SVG for crisp rendering and easy recoloring. Good reason to do it, and it breaks the pattern above, because <svg> takes no alt.

For an SVG sitting on its own, not inside a link, put role="img" on the svg element and a <title> as its first child:

<svg role="img" focusable="false" viewBox="0 0 120 32">
  <title>Acme</title>
  <path d="..."/>
</svg>

Scott O'Hara tested this combination and found it announces as an image or graphic with the right name in every browser and screen reader pairing he tried, as long as the SVG stands alone. Two catches. The <title> element also shows as a native tooltip on hover, so use aria-label on the svg instead if you don't want that. And focusable="false" only exists to stop Internet Explorer and pre-Chromium Edge dropping the svg into the tab order, so you can skip it if you've stopped supporting those.

Inside a link, which is where your header logo lives, that pattern gets shakier. O'Hara's testing found SVGs in links failing to hand over an accessible name in IE 11 with NVDA and in the old EdgeHTML Edge with JAWS. Both of those are dead now, so the practical risk in 2026 is small, but his recommendation is still the more robust markup: hide the SVG and name the link itself.

<a href="/" aria-label="Acme">
  <svg focusable="false" aria-hidden="true" viewBox="0 0 120 32">
    <path d="..."/>
  </svg>
</a>

A visually hidden <span> inside the link works the same way and survives translation tools better than aria-label does. Either way, aria-hidden="true" on the svg is the equivalent of alt="", and it's only safe here because the link picks up the name instead. Never leave an svg hidden inside a link that has no other name, for the same reason you never leave an empty alt there.

If you're still deciding how to serve the file at all, PNG vs SVG for logos covers the tradeoff, and the header, favicon, and footer checklist covers where each copy of the mark needs to go. A browser tab icon doesn't get an alt attribute at all, but it has its own format questions, which ICO vs PNG vs SVG favicons covers.

Keyword stuffing is the failure that costs you something

alt="best affordable plumber Chicago emergency plumbing services logo" still turns up on small business sites, usually dropped in by a plugin or a well meaning contractor. Google's image documentation is direct about it: "Avoid filling alt attributes with keywords (also known as keyword stuffing) as it results in a negative user experience and may cause your site to be seen as spam."

It hurts the accessibility side more than it hurts search. That string is the accessible name of a link that appears in the header of every page, so somebody navigating by links hears the whole thing dozens of times in a session.

Alt text does real work on images that are the subject of a page: product photos, diagrams, charts. Google says it uses alt text "along with computer vision algorithms and the contents of the page to understand the subject matter of the image". Your header logo isn't that. It's a repeated piece of site furniture, it won't move rankings, and treating it as a keyword slot wrecks the job it's actually doing. If you want Google to recognize your logo as your logo, that runs on a different mechanism, covered in logo schema markup.

What you can stop worrying about

Nobody needs the word "logo" in the alt value. WebAIM says it's "usually not an important part of the image's content or function". Same goes for "image of" and "graphic of", which WebAIM calls redundant "since screen readers already announce 'graphic' along with the alt text".

The 125 character limit isn't a rule anyone wrote down. It comes from JAWS versions in the mid 2000s that split long alt text into 125 character chunks rather than cutting it off, and people mistook chunking for truncation. WCAG sets no character limit anywhere. Short alt text is still better, because short is easier to listen to, but you aren't violating anything at 130 characters.

File names, though, are worth worrying about. WebAIM's 2026 report counts them among the "questionable or repetitive" values that push the share of images with a missing or bad alt attribute past one in four.

How to check what you actually have

Open the header logo in your browser's dev tools, find the element in the accessibility pane, and read the computed accessible name. That's the string that gets announced, after aria-label overrides and everything else has been applied. If it says "logo.png", you've found your bug.

Then tab through the page with the screen reader your OS already ships, VoiceOver on macOS or Narrator on Windows, and listen to the first three stops. Two minutes, and it's the only check that tells you what somebody actually hears instead of what your markup claims to do.

Most of this comes down to deciding what the mark is doing in each spot before you type anything into the attribute. If you're still assembling the files themselves, Brandize gives you the logo variations and formats for the header, footer, and favicon at brandize.me, which at least removes the excuse that you only had one PNG to work with.