Inclusive graphics
Accessible SVG: text alternatives, titles, focus, and motion
The correct accessibility pattern depends on the SVG's purpose. A decorative flourish, a labeled icon button, an informative diagram, and an interactive chart should not all expose the same semantics.
Decide what the graphic communicates
Start with a plain-language question: what information or action would be lost if the SVG did not render? If nothing is lost because nearby text already communicates the same idea, the SVG is decorative. If it conveys a name, status, trend, instruction, or control, it needs an equivalent that fits that purpose.
Do not describe every shape and color by default. A useful alternative communicates meaning, not drawing instructions. A company logo may need the organization name. A warning icon beside visible text can be hidden. A chart needs its conclusion and underlying data, not a list of path coordinates.
Decorative SVG patterns
For an SVG loaded through an img element, use an empty alt attribute so assistive technology can skip it:
<img src="divider.svg" alt="" width="240" height="24">For inline decorative SVG, use aria-hidden="true" and prevent focus. This is common for an icon inside a button that already has a visible or accessible name.
<button type="button">
<svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">...</svg>
Download SVG
</button>Keep the accessible name on the HTML control. That is more robust than making a nested path or SVG element act as the button label.
Informative inline SVG
An inline SVG can reference a title and a longer desc with aria-labelledby. Use unique IDs, especially when the same component appears more than once.
<svg role="img" aria-labelledby="chart-title chart-desc" viewBox="0 0 320 180">
<title id="chart-title">Monthly export volume</title>
<desc id="chart-desc">Exports rose from 120 in January to 310 in June.</desc>
...
</svg>Screen-reader behavior can vary by embedding method and browser, so test the final page rather than assuming a title alone is sufficient. The current W3C SVG Accessibility API Mappings draft describes how SVG names and descriptions reach accessibility APIs and recommends explicitly linking title and desc for fallback support. The document also labels itself as work in progress, so implementation testing remains essential.
For a complex chart, include a nearby HTML summary and data table. That gives everyone a searchable, copyable, and zoomable alternative.
Icons and controls need a reliable name
An icon-only HTML button should receive an aria-label or visually hidden text on the button itself. Avoid placing the click handler only on an SVG path. Native HTML controls provide keyboard behavior, focus management, and disabled states that are difficult to recreate correctly.
If parts of an SVG are interactive, each operable item needs a programmatic name, keyboard access, a visible focus indicator, and a clear state. Complex interactive charts may be easier to support with synchronized HTML controls and summaries rather than dozens of focusable vector nodes.
Contrast, color, text, and zoom
Do not use color as the only way to distinguish states or series. Add labels, patterns, line styles, markers, or an adjacent legend. Check text and meaningful graphical-object contrast against their backgrounds. Thin strokes can disappear even when their color values technically differ.
Prefer real HTML text for body copy. SVG text is appropriate when it is part of a diagram, but it should remain legible at zoom and should not be converted to paths unless visual fidelity is truly more important than selection, translation, search, and accessibility.
Motion and final testing
Respect prefers-reduced-motion for animated transforms, paths, filters, and auto-moving diagrams. Essential state changes can remain, but large or continuous motion should stop or become simpler. Never make critical instructions visible only during a brief animation.
- Classify the SVG as decorative, informative, or interactive.
- Provide the shortest useful text alternative at the correct HTML level.
- Keep native controls responsible for interaction when possible.
- Test keyboard order and visible focus.
- Check high zoom, narrow screens, forced colors, and reduced motion.
- Use at least one real screen reader on the final embedded page.
- Verify that sanitized or optimized output did not remove required titles, descriptions, or labels.
SVG Vector Lab preserves standard SVG source for inspection, but accessibility depends on how the final file is embedded and used. After editing, follow the safe optimization checklist without stripping meaningful metadata.