SVG Accessibility

SVG accessibility ensures scalable vector graphics convey their information to screen reader users through proper labeling, roles, and descriptive content. Accessible SVGs serve as alternatives to images, icons, and complex diagrams.

What Is SVG Accessibility

SVG (Scalable Vector Graphics) elements can represent simple icons, complex illustrations, charts, and interactive graphics. Their accessibility requirements depend on their purpose: decorative SVGs should be hidden; informative SVGs need text alternatives.

Unlike raster images that use simple alt attributes, SVGs support multiple accessibility mechanisms including title elements, desc elements, ARIA attributes, and focusability. The flexibility also creates complexity: multiple valid approaches exist.

WCAG Success Criterion 1.1.1 (Non-text Content) applies to SVGs just as it does to images. Informative SVGs need text alternatives. Decorative SVGs should be implemented so assistive technologies ignore them.

How SVG Accessibility Works

For simple informative SVGs, the combination of role=“img” and aria-label provides accessible names:

The role=“img” tells assistive technologies to treat the SVG as an image. The aria-label provides the accessible name. This pattern works well for icons and simple graphics.

For more complex SVGs, internal title and desc elements provide accessible content:

The title element provides the accessible name; desc provides additional description. The aria-labelledby attribute explicitly associates these elements with the SVG. IDs connect the pieces.

Decorative SVGs use aria-hidden=“true” to hide from assistive technologies:

This prevents screen readers from attempting to announce the SVG content. For purely decorative graphics, this provides the clearest implementation.

Focusable SVGs require additional consideration. By default, SVG elements can receive focus in some browsers. Adding focusable=“false” prevents unwanted focus on decorative or non-interactive SVGs. Interactive SVGs may intentionally receive focus with proper keyboard handling.

Key Considerations

• Determine whether each SVG is informative, functional, or decorative
• Use role=“img” with aria-label for simple informative SVGs
• Use title and desc with aria-labelledby for complex SVGs
• Apply aria-hidden=“true” to decorative SVGs
• Add focusable=“false” to prevent unwanted focus on decorative SVGs
• Ensure inline SVGs include accessibility attributes directly
• Test with screen readers since SVG support varies

Common Questions

Should external SVG files or inline SVG be used?

Inline SVGs offer the most reliable accessibility support because attributes apply directly. External SVG files referenced via img element work like any image, using standard alt text.

SVGs referenced via object, embed, or CSS background have varying accessibility support. Inline SVG provides the most control over accessible naming and description.

How should icon fonts compare to SVG icons for accessibility?

SVG icons generally offer better accessibility than icon fonts. SVGs can include proper semantics, while icon fonts often insert private-use Unicode characters that screen readers may attempt to announce incorrectly.

Icon fonts require aria-hidden on the icon element plus separate accessible labeling. SVGs can be self-labeling with proper attributes. Both can work accessibly, but SVG provides more straightforward implementation.

What about animated or interactive SVGs?

Animated SVGs should respect prefers-reduced-motion preferences, pausing or reducing motion for users who have indicated motion sensitivity.

Interactive SVGs that respond to user input need proper focus handling, keyboard support, and state communication. Role attributes (button, slider, etc.) can make interactive SVG elements behave like standard widgets for assistive technology.

Summary

SVG accessibility uses role=“img” with aria-label for simple graphics, title and desc elements for complex diagrams, and aria-hidden for decorative graphics. The flexibility of SVG requires careful attention to which accessibility mechanism suits each use case, with testing across screen readers to verify implementation.