This offers developers a "standards compliant" way to have high fidelity control over the graphics of their web offering. Polished visual experiences usually reserved for the desktop, or for browser plugins (which are not web standards) can now be delivered in a web page.
Canvas sucks though.
You might say wat!? I'm going to naively try to condense thousands of words into a few here. There have been a great many splendid web experiences built with a good underlying document structure (DOM) consisting of the elements that have been around a lot longer than canvas. Combined with CSS, ARIA, and js it is possible to provide innovative web experiences for everyone. The elements and structure provide meaning that can be leveraged for accessibility, for searching, for styling etc. With canvas we lose that.
So what can we do for developers that need to use canvas?
Well, presumably if they are creating anything sophisticated there is meaning and structure somewhere. For example right now it might be in home-grown js data structures. If we could just find a way to have a consistent way for web developers to store structure then we have a glimmer of hope in providing accessibility tools with the information they need. What structure should we suggest web developers use? Well, how about HTML?
February 29th, 2012 we landed support for canvas accessibility in the development version of Firefox (which is now Firefox 13). In a nutshell a web developer can use the power of html inside canvas. The html will not itself be drawn on the screen, since that would circumvent the web developer's reason to choose canvas, and just be silly, but in all other respects this HTML will be "alive". Web developers will be able to utilize the built in keyboard navigation and event handling of the web, and the accessibility of the web.
Steve over at TPG has a good blog about HTML5 canvas accessibility support in FF and IE.