Skip to content

Choosing HTML, SVG, Canvas, or WebGL for Real-Time Graphics

While building a personal project that visualizes live operational data on a map, I ran into a classic frontend challenge: I needed to render thousands of moving coordinates at 60 FPS while keeping the interface keyboard-navigable, clickable, and accessible to screen readers.

I quickly discovered that treating the UI as an "all-or-nothing" choice between the DOM and a <canvas> element was the wrong approach. HTML, SVG, Canvas, and WebGL each handle different trade-offs between rendering throughput and browser ergonomics.

I’m sharing my notes on how to combine these surfaces into a clean hybrid architecture—and a simple rule of thumb for deciding which tool to reach for.

Navigate this post

How each surface works

The core technical trade-off comes down to retained mode (DOM) vs. immediate mode (pixels):

  • HTML (Retained): Best for structural UI (controls, forms, sidebars, data tables). The browser manages layout reflows, keyboard focus, and accessibility trees automatically.
  • SVG (Retained): Best for resolution-independent vector graphics (routes, icons, simple charts). Each shape is an addressable DOM element with native event listeners and CSS styling.
  • Canvas 2D (Immediate): Best for high-frequency 2D redraws. Drawing commands paint directly to a flat pixel grid. The browser only sees one canvas image, so hit-testing and accessibility must be handled in your application code.
  • WebGL (Immediate / GPU): Best for massive datasets (50,000+ entities) and 3D scenes. It streams geometry directly to GPU shaders for maximum rendering throughput.
Surface Type Addressing Accessibility Best Fit
HTML / SVG Individual DOM nodes Built-in UI controls, labels, and moderate vector counts
Canvas / WebGL Flat pixel buffer Manual (requires fallback) Dense data, high-FPS animations, and frequent redraws

The hybrid architecture pattern

You don't need to force an entire application into a single rendering technology. The cleanest architecture for a real-time dashboard is a hybrid approach: use HTML for controls and data tables, layered alongside Canvas or WebGL for high-frequency graphics.

---
title: "Hybrid Visualization Architecture"
---
flowchart TB
    accTitle: Hybrid Visualization Architecture
    accDescr: Central state drives both accessible HTML UI and high-performance canvas rendering.
    A["Central App State (Zustand / Redux / Signals)"] --> B["HTML Controls & Companion Table"]
    A --> C["Canvas / WebGL Viewport"]
    B <--> D["Synchronized Selections & Filters"]
    C <--> D

By keeping selection, timestamps, and filters in a central state store:

  1. Clicking an item on the canvas updates the HTML detail pane.
  2. Navigating an HTML data table highlights the corresponding entity on the map.
  3. You can swap out your graphics engine (e.g., migrating from SVG to Canvas) without rewriting your application controls or detail panels.

Comparison matrix: choosing by workload

Surface Sweet Spot What the Browser Handles What You Must Build
HTML Forms, tables, overlays, panels Semantics, focus, ARIA tree Application state & layout
SVG Interactive diagrams, routes (< 2,000 nodes) Per-element events & CSS styling DOM scale management
Canvas 2D Dense 2D charts, high-frequency updates Fast bitmap rasterization Click hit-testing & keyboard focus
WebGL Massive scale (50,000+ points), 3D GPU shader execution Buffer management & shaders

Rule of thumb: Default to HTML and SVG for free accessibility and built-in event listeners. Reach for Canvas or WebGL only when DOM node counts start choking the main thread.

Solving the accessibility gap

Because Canvas and WebGL output a flat bitmap, screen readers and assistive tools cannot inspect what is drawn inside them.

If you use Canvas or WebGL for your visualization, build an accessible HTML companion view alongside it:

  • Provide a synchronized HTML table or list: Let screen readers and keyboard users inspect and filter raw data independently.
  • Avoid color-only encoding: Always pair color codes with text labels or distinct icons.
  • Announce dynamic events: Use ARIA live regions (aria-live="polite") to announce real-time alerts or threshold breaches.
  • Support keyboard navigation: Ensure zoom, pan, and selection have keyboard shortcuts or visible HTML button equivalents.

For specification details, see the WHATWG Canvas Accessibility Guidelines.

My default rule of thumb

When starting a new real-time visualization project, follow this progression:

  1. HTML First: Build the page layout, controls, data tables, and modal drawers with semantic HTML.
  2. SVG for Shapes: Use SVG for charts and vectors until DOM count causes frame drops.
  3. Canvas 2D for Throughput: Switch the graphics layer to Canvas 2D if you need frequent full-screen repaints.
  4. WebGL for Scale: Step up to WebGL (or libraries like Pixi.js / Deck.gl) only when rendering tens of thousands of dynamic points.

Conclusion

Real-time dashboards don't require you to choose between performance and accessibility. By decoupling your state management from your rendering layer, you can use HTML and SVG where accessibility matters most, and lean on Canvas or WebGL where raw graphics horsepower is required.

Start with the simplest DOM-based approach, layer on Canvas when performance bottlenecks appear, and always keep an accessible HTML view in sync.

References and further reading

Open the complete reference catalog

Primary Sources