Accessible SVG

Introduction

An SVG can be a decorative flourish, a labeled logo, a data visualization, or the visible part of a button. Those cases require different accessibility behavior. There is no single attribute set that makes every SVG accessible.

Start by identifying the graphic's purpose in the surrounding page. Then expose equivalent meaning without repeating nearby text.

Choose by purpose

Meaningful image file

<img
  src="checkout-flow.svg"
  alt="Checkout flow from cart to payment confirmation"
  width="640"
  height="360"
>

Alternative text should communicate purpose, not list every shape. A complex diagram may need a longer explanation in adjacent HTML.

Decorative inline SVG

<span class="notice">
  <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">
    <path d="..." />
  </svg>
  Saved successfully
</span>

The visible text already conveys the message, so announcing the icon would add noise.

Icon-only control

<button type="button" aria-label="Close dialog">
  <svg aria-hidden="true" viewBox="0 0 24 24">
    <path d="M6 6l12 12M18 6 6 18" />
  </svg>
</button>

The button owns the action and accessible name. The SVG remains visual decoration inside a native interactive element.

Common mistakes

Giving every inline SVG a title

Titles can duplicate nearby labels and behavior varies by embedding method and assistive technology. Name the content at the appropriate semantic layer.

Making SVG itself behave like a button

Adding a click handler to a graphic does not automatically provide keyboard operation, focus, or button semantics. Use a button or link around it.

Using filenames as alternative text

Names such as icon-check-green.svg describe implementation, not meaning. Write the text a user needs in context.

Hiding a meaningful chart

An attractive chart can contain essential information. Provide the conclusion, values, or an accessible data representation in HTML.

Relying on color alone

Status diagrams and charts need labels, patterns, shapes, or text in addition to color differences.

Review workflow

1. 1
   Identify whether the SVG is decorative, meaningful, complex, or interactive.
2. 2
   Locate nearby text that may already provide its name or description.
3. 3
   Apply the embedding pattern appropriate to image, inline markup, or control.
4. 4
   Navigate the page with a keyboard and verify focus order.
5. 5
   Inspect the accessibility tree or use a screen reader.
6. 6
   Test high zoom, forced colors, and dark mode where relevant.
7. 7
   Recheck after optimization or component transformation.

Best practices

• -Decide accessibility at the point of use.
• -Prefer native buttons and links for interaction.
• -Keep alternative text concise and purpose-driven.
• -Provide nearby detail for complex diagrams.
• -Avoid duplicate announcements.
• -Ensure visible focus and sufficient contrast.
• -Preserve titles and labels that are intentionally referenced by IDs.

FAQ

Should inline SVG always have `role="img"`?

No. Use image semantics when the SVG represents meaningful image content. Decorative inline SVG should usually be hidden instead.

Is a `<title>` element enough for a complex diagram?

Usually not. Complex information often needs visible explanatory text, a table, or another equivalent representation.

Should decorative images use no alt attribute?

For <img>, use an empty alt="". Omitting the attribute can cause assistive technology to announce the filename.

Can optimization remove accessibility data?

Yes, depending on settings. Review referenced titles, descriptions, IDs, and ARIA attributes after optimization.

Use the WAI Images Tutorial and WCAG text alternative guidance for context-specific decisions.