Inline SVG gives developers precise control over styling, animation, and layout, but it also creates accessibility decisions. An icon can be meaningful, decorative, interactive, or part of a larger label. Each case needs a slightly different treatment.
First decide whether the SVG adds meaning
If an icon repeats nearby text, it is probably decorative. A search button with visible text that says Search does not need the magnifying glass to be announced separately. In that case, set aria-hidden=”true” on the SVG or make sure the parent control already has a clear accessible name.
If the SVG carries information by itself, it needs a label. Examples include status icons, warning symbols, standalone logos, chart markers, or an icon-only button. The user should receive the same meaning whether they see the graphic or use assistive technology.
Use labels on the control, not only the icon
For icon-only buttons, label the button. A button with aria-label=”Download SVG” is more reliable than putting the only label inside the SVG. The same principle applies to links. The interactive element should explain the action.
When title and desc are useful
The SVG title and desc elements can describe a meaningful graphic. They are most useful for standalone illustrations, logos, and informational graphics. For simple UI icons, aria-label on the button or link is often simpler and more predictable.
Avoid duplicate announcements
A common problem is announcing the same meaning twice. For example, a button might include visible text, an aria-label, and a titled SVG that all say the same thing. Screen reader users then hear redundant labels. Keep the accessible name clear and singular.
Decorative icon pattern
For decorative icons inside labeled controls, use aria-hidden=”true” and focusable=”false” on the SVG. This keeps the icon out of the accessibility tree and prevents older browsers from focusing it unexpectedly.
Meaningful icon pattern
For a standalone meaningful SVG, provide a title or aria-label, and make sure the surrounding content does not already provide the same information. If the SVG is complex, include nearby visible explanatory text as well. Accessibility improves when meaning is available to everyone, not only hidden in attributes.
Testing checklist
- Can the user understand the page if icons do not load?
- Does each icon-only button have a clear label?
- Are decorative icons hidden from assistive technology?
- Are important graphics described in nearby text?
- Did you avoid duplicate labels?
Good SVG accessibility is mostly about intent. Decide what the icon means, then make the markup match that role.
Accessible SVG patterns for website interfaces
Good SVG accessibility starts with intent. If the SVG is decorative, hide it with aria-hidden and let the nearby text do the work. If it is meaningful, give the control or graphic a clear accessible name. The W3C WAI images tutorial is a useful reference for deciding whether an image needs alt text, nearby text, or decorative handling.
Tools for reviewing accessible SVG markup
Before shipping an inline SVG, clean the markup with the SVG Prettifier, preview the rendered output in the SVG Viewer, and convert framework code with SVG to JSX or SVG to TSX. Accessibility labels should survive the conversion step instead of being added as an afterthought.
Related SVG workflow guides
For component libraries, pair this guide with How to prepare SVG icons for React components. For production cleanup, use How to optimize SVG files before shipping. If the graphic looks cropped, check the SVG viewBox repair guide.