Accessible SVG: title, desc, and aria-hidden Explained

This is where a lot of beginners get confused. They hear about <title>, <desc>, aria-hidden, role="img", and aria-labelledby, and it all starts to sound more complicated than it really is. The good news is that the core idea is simple: some SVGs should be announced, some should be described, and some should be ignored.

Start with the main question

Before you add anything, ask one thing:

Does this SVG communicate information, or is it only decorative?

If the SVG is meaningful, it needs an accessible name, and sometimes a longer description too. If it is purely decorative, it is usually better to hide it from assistive technology so it does not create noise. MDN’s ARIA guidance says aria-hidden="true" removes an element and its children from the accessibility tree, and specifically calls out decorative icons and images as common examples. W3C’s decorative images guidance makes the same larger point: decorative visuals should not be exposed like meaningful content.

What <title> does

In SVG, <title> provides a short text description. MDN describes it as the accessible short-text description for an SVG container or graphics element. The text is not rendered as part of the graphic itself, though browsers often show it as a tooltip. MDN also notes that, for backward compatibility, the <title> should be the first child of its parent.

In practice, <title> is the quick label. It is the part that answers, “What is this graphic?”

For example, if you have an inline SVG of a search icon that actually conveys meaning, a title like “Search” gives it a short, useful accessible name.

What <desc> does

<desc> is for the longer explanation. MDN defines it as an accessible long-text description for an SVG container or graphics element. Like <title>, its text is not shown visually on the page.

This makes <desc> useful when the graphic says more than a short label can cover. A simple icon often does not need it. But a chart, diagram, illustration, or complex animated graphic may benefit from a longer explanation so someone using assistive tech gets more context.

So the easiest way to remember it is this:

<title> is the short name.
<desc> is the longer explanation.

Why role="img" often appears with accessible SVG

When you use inline SVG in HTML, there is no alt attribute like there is on a normal <img>. MDN’s SVG-in-HTML guide recommends role="img" so assistive technologies treat the SVG as an image, then naming it with <title> or with ARIA labeling.

That is why accessible inline SVG examples often look like this:

<svg role="img" aria-labelledby="logoTitle logoDesc" viewBox="0 0 100 100">
  <title id="logoTitle">Company logo</title>
  <desc id="logoDesc">A circular logo with a lightning bolt in the center.</desc>
  <!-- SVG shapes here -->
</svg>

This pattern works well because the SVG is clearly treated as one image, while the title and description provide useful text alternatives.

When aria-labelledby is better than relying only on <title>

This is an important detail. MDN says that if an element can be described by visible text, it is recommended to reference that text with aria-labelledby instead of relying only on the SVG’s <title>. MDN also explains that aria-labelledby defines an accessible name by referencing other elements in the DOM, and that it has very high precedence in accessible name calculation.

That means if your SVG already sits next to a visible heading or label, the cleanest approach is often to point the SVG at that existing text rather than inventing a separate title inside the SVG. This helps keep the visible and accessible labels aligned.

What aria-hidden="true" does

aria-hidden="true" removes the element and all of its children from the accessibility tree. It does not visually hide the SVG on screen. It only hides it from assistive technology. MDN is very explicit about that.

This is exactly what you want for decorative SVGs.

For example, if a button already has visible text and the SVG inside it is only a visual accent, hiding the SVG from assistive tech often makes the experience better because it avoids redundant or confusing output. MDN even gives a similar example with an icon inside a button.

<button>
  <svg aria-hidden="true" viewBox="0 0 24 24">
    <!-- decorative icon -->
  </svg>
  Download
</button>

In that case, the button text already does the real accessibility work. The icon is decoration, so it should stay out of the way.

The most common mistake with aria-hidden

The biggest mistake is hiding something that is actually meaningful.

If the SVG communicates information, identifies an action, or is the only visible label for an interactive control, aria-hidden="true" is usually the wrong choice because it removes that content from the accessibility tree. MDN also warns not to use aria-hidden="true" on focusable elements, and not to put it on ancestors of focusable elements, because hidden content should not still be interactive.

So the rule is simple:

If the SVG matters, label it.
If it does not matter, hide it.

A practical way to choose

Here is the easiest mental model for most SVG cases:

If the SVG is a meaningful image, use role="img" and give it a short name with <title> or aria-labelledby. Add <desc> when the graphic needs extra explanation. If the SVG is only decorative, use aria-hidden="true". This matches MDN’s current SVG accessibility guidance and its ARIA guidance on hiding decorative content.

Final thoughts

Accessible SVG is not really about memorizing lots of attributes. It is about making the right decision for the role the graphic plays.

Use <title> for the short name. Use <desc> for the longer explanation. Use aria-hidden="true" when the SVG is decorative and should be ignored. And when visible text already labels the graphic, prefer aria-labelledby so the accessible name comes from what users can actually see.

That is the foundation. And once you understand that foundation, accessible SVG becomes much less intimidating.