Back to blog

Create a Shareable SVG Demo That Scales and Stays Accessible

Use viewBox, meaningful text alternatives, CSS variables, and restrained animation in standalone SVG examples.

Jul 29, 2026ShowYourCode Editorial Team

SVG is ideal for diagrams, icons, and small data illustrations because its coordinate system is independent of display pixels. The most common sharing mistake is to treat it like a fixed screenshot.

Define a viewBox and let CSS control the rendered width. The four values describe the internal coordinate space; they do not force a physical size. Avoid leaving large invisible margins around the artwork because those margins become part of every responsive layout.

<svg viewBox="0 0 640 360" role="img" aria-labelledby="title desc">
  <title id="title">Request lifecycle</title>
  <desc id="desc">A request moves from browser to server and database.</desc>
  <!-- shapes and labels -->
</svg>

If the graphic conveys information, provide a concise title and description. Decorative SVG should instead be hidden from assistive technology. Keep essential labels as text rather than converting them to paths; text remains searchable, selectable, translatable, and more likely to respond to user font settings.

Use CSS custom properties for palette decisions and test light and dark backgrounds. Thin low-contrast strokes often vanish when a thumbnail is generated. For a diagram, shape, position, and label should carry meaning together rather than relying on color alone.

Animation needs a purpose. A path that reveals sequence can help comprehension; a perpetual bounce usually competes with it. Respect prefers-reduced-motion and ensure the final state communicates the same information without movement.

Before sharing, remove editor metadata, unused definitions, embedded raster images you do not own, and external font dependencies. Test the standalone SVG at several container widths and at 200 percent zoom. A robust SVG demo remains legible as a card preview, a full-page illustration, and a downloaded file.

Choose the correct SVG delivery mode

Inline SVG can inherit CSS, expose individual elements to scripts, and participate in the accessibility tree. An SVG loaded through an img element behaves more like an image and has a smaller interaction surface. An object or iframe creates another document with different navigation and security behavior. Choose the mode from the required interaction, not convenience, and record the choice in the demo.

Use a meaningful viewBox and avoid hardcoding both dimensions when the graphic must scale. Test very small and very large containers, high zoom, and translated surrounding text. Preserve aspect ratio intentionally; silent cropping or stretching can change the meaning of diagrams and icons.

Make the graphic understandable

Decorative SVG should be hidden from assistive technology. Informative SVG needs a concise accessible name, usually supplied by surrounding markup or a title relationship, plus adjacent prose for complex diagrams. Do not expose hundreds of meaningless path nodes. For interactive regions, use real focusable controls where possible and provide equivalent text actions outside the graphic.

Never encode the only distinction in color. Add labels, patterns, shape, or position and verify contrast in light, dark, and forced-colors modes. Respect reduced motion and provide a static state for animated explanations.

Optimize without destroying semantics

Remove editor metadata, unused definitions, excessive numeric precision, and invisible paths. Keep IDs that are referenced by gradients, masks, clips, filters, labels, or CSS. Run optimization on a copy and compare rendering and the accessibility tree afterward. Aggressive ID cleanup can create a valid-looking file with broken relationships.

For icon sets, align coordinate systems and stroke behavior so symbols scale consistently. For data graphics, reduce unnecessary points before adding filters or blur effects. Measure file size and paint cost on the target device; a compact source string can still be expensive to render.

Treat SVG as active content

SVG may contain scripts, event attributes, links, external resources, animation, and foreign HTML. Do not insert user-supplied SVG directly into trusted DOM. If only an image is needed, validate and serve it through a non-executable image context. If inline features are required, sanitize with an SVG-aware allowlist and reject dangerous protocols, external references, event handlers, and unsupported namespaces.

Test malformed markup, encoded URLs, nested links, foreignObject, filters, and large path collections. Apply size and complexity limits. A generic HTML regex is not sufficient because SVG has its own elements, attributes, and namespace behavior.

Build a reproducible review fixture

Include the source, render mode, expected dimensions, and interaction instructions beside the output. Test external resources blocked, keyboard traversal, zoom, dark mode, and export. When raster export is required, specify background, scale, and target size; when SVG export is required, confirm the file opens independently without private fonts or stylesheets.

End with licensing or provenance for artwork and a list of known renderer differences. That context allows another developer to reuse the example safely and prevents a visually successful SVG from hiding accessibility, portability, or security failures.