Web charts with HTML5 + Flash

ZingChart hopes to end the war between HTML5 and Flash in web-based charting:

Today we launched the first charting library that renders charts and graphs in both HTML5 <canvas> and Flash. Rather than join the Flash vs. <canvas> debate, we built a version that renders charts in both frameworks. With the recent launch of the iPad, we hope ZingChart Flash + HTML5 <canvas> helps the growing data visualization community focus on building great visualizations rather than worrying about compatibility.

For you visual learners and tinkerers, here’s the demo:


via ZingChart.

Next question: How accessible is it?

18 thoughts on “Web charts with HTML5 + Flash

  1. By the looks of it at a quick glance, not very: the data lives in a set of JSON, no actual data tables anywhere in sight.

    That’s what I thought. And that’s the problem with all of this Flash-vs.-Canvas debate. It mostly ignores accessibility.

    Whereas if the charts were generated with HTML5 or XHTML 1.0 and CSS, they could contain the fully accessible data, a la Eric Meyer’s HTML/CSS charts and graphs at A List Apart, which are completely accessible as data.

    Of course, Flash can also be accessible.

    But with the proper CSS knowledge, as Eric’s charts for the ALA survey results show, you don’t need to use Flash and Canvas; you can simply use HTML5 and CSS and have great design and full accessibility.

    Of course, Eric’s charts weren’t created on the fly, and these charts are. I wonder if they could harness their engine to create CSS charts on the fly instead (with fully exposed HTML data).

  2. This is great in regards to forward progression. Although I still find little justification for the Flash versions existence. I’d love to see an accessible Table as well.

    I’ve wanted non Flash Google Analytic Graphs for forever, hopefully this is a step in that direction.

  3. When facing any fight between two major influencers, or identity, never pick a side. The best way is to keep doing what we do best, and focus rather on growing, extending, and inspiring the community where we belong to.
    Thank you for this note. It’s a good reminder. Here at work, flasher guy is very sad, and it is always a little weird to consider all this knowledge is not useless. Designing for accessibility and compatibility remains a concerned for us.

  4. I guess it’s a nice try. Please correct me if I’m off here, but aren’t there some documented and/or noted accessibility issues with the canvas tag?:


    At least we now have the promise of something better than Flash for charting. I’m hoping this will lead others to improve on the concept a bit more and keep pushing on.

    Java charts were eventually replaced (mostly) with Flash equivalents. Here’s to hoping for a standard. I’d go as far as to say that we should consider an HTML5 chart or graph tag; we use charts and graphs so much in apps these days it makes perfect sense.

  5. While it may not include some of the interactivity of the charts you posted, this script generates canvas charts from accessible HTML table data, and supports quite a few chart types.

    Fantastic, Scott!

    “Visualize is one of the 12 fully-accessible, project-ready, progressive enhancement-driven widgets that accompanies our new book, Designing with Progressive Enhancement.”


    That is the way to do it.

    I kind of worry that developers will get caught up in their own underwear doing Canvas or Flash or (as in this case) both, without considering if there is a simpler, accessible, semantic way to do things.

    Glad you’re doing what you’re doing.

    Your book looks fantastic, BTW.

    should have bitly’d that I suppose… sorry :)

    No worries, I took care of it. ;)

  6. For purely experimental purposes it seems fine to try to find solutions that are not accessible, but to actually use them? Tsk tsk. ;) Right? That’s one of the major lessons we all take away from DWWS.

  7. While the JSON format isn’t very accessible on its own, it’s quite straightforward to generate an HTML table with the same data.

    If programming scares you, there’s another accessible option:

    The Raphael JS library can generate SVG line graphs from HTML tables. Here’s theirexample (view source).

  8. So, the data is fed in as some form of JSON; there’s nothing preventing it from being used in an accessible manner (especially by looking at their demo code, which can take JSON in a string as well as retrieving it from a URL).

    It actually makes a bit more sense to me to do it that way, since now all you’re doing is using the JSON as a format for presenting the raw data to the charting utility; it could just as easily be taking JSON generated by the same mechanisms that are used by the other “more accessible” charting utilities to retrieve their data; you could be using JSON that’s generated server-side and output both a chart and a data table, or ultimately anything else.

  9. It is easy with ZingChart to have a script that generates the standard charts from an HTML table. We used HTML5 data-X attributes for some basic chart controls. Here’s a link if you want to see yourself

    table bindng example with jquery and ZingChart

    Viewsource or turn off your Flash to see how it would fallback. Mind you that this example uses the Flash render but the Canvas is identical in approach since it uses the same JSON packet. Likely I think that this approach is about as accessible as you can be with charted data.

    Thomas speaking for ZingChart

  10. I assume the Flash rendering is for performance reasons in slower rendering engines (IE). Seems like Canvas would be preferred in all situations in which it was natively supported in the browser (all but IE), as an alternative to excanvas (IE emulation using VML).

    For my money, I’d value features over Flash rendering, as long as it still worked as is in IE (albeit slower). That’s why I’d recommend jqPlot over this solution. It uses canvas and works in IE6+.

    The hard part isn’t creating a chart from a table (accessibility concerns), the hard part is getting it to render (fast & correct) on as many user agents as possible.

  11. The hard part isn’t creating a chart from a table (accessibility concerns)

    Really? Then why does jQPlot not do that? I’d say, creating a chart from a table is the hard part because we have here three JS plugins that draw charts, and only one of them is doing so using data extracted from a table.

  12. Thanks for the kind words, Jeffrey.

    There are a couple more things to consider when charting from a table, from an accessibility perspective…

    If you use display: none; to hide the table after charting it, the table will be inaccessible to users with screen readers, which defeats the purpose of the approach. To hide the table from sighted users once the chart is generated, we recommend positioning the table off the page (position: absolute; left: -9999px;), which will hide it visually while keeping it accessible to screen readers. It looks like the Raphael.js demo above hides the table in this way (great library too, BTW).

    Also, on the generated chart markup, we assign an ARIA role=”img” attribute to the chart container to describe the role it is playing, and an aria-label attribute containing the text from the table’s caption element, which serves as a title/description for the chart (aria-label=”Chart representing data from the table: 2009 Employee Sales by Department” ). Props to our tech editor James Craig, WAI-ARIA for helping us work this out.. :)

    It would be great to see some of the other scripts with admittedly richer charting features provide a simpler means of generating their charts from a table. I haven’t looked through all of them, but many of the examples we see are pretty complicated for the average end-user. In Visualize, creating a chart is just $(‘table’).visualize();

  13. Hey all,

    Great feedback and discussion. I wanted to add some thoughts that you may or may not have seen (from ZingChart team member), to continue the flow of ideas:

    – @Antoine and @Zach – Canvas-only charting is great for certain purposes i.e. simple graphs with fewer datapoints and few features (gradients, shadows, etc). We’ve found that as you add complexity, Flash begins to beat Canvas from a performance perspective. If you haven’t yet — run our with 3 x 1,000 points on a Bar Chart. Feel free to try it in IE also, and please do submit your results if it finishes rendering.

    Long story short: we realize that the vast majority of end users (site visitors, that is) want a) a chart or graphic that works everywhere, b) speed, and c) interactivity/features. They don’t care about how it’s made. By launching ZingChart in Flash and HTML5, we’re hoping to help developers make satisfying those end users’ needs very easy.

    We’ve got quite a bit in development coming down the pike so do stay in touch. Say hello on twitter at .

    All feedback is welcome. Thanks.
    Andrew from ZingChart

Comments are closed.