Future Web Accessibility: canvas

This is the sixth in a multipost series about the immediate and likely future of web accessibility. Each week or so I’ll discuss a different upcoming technology, tag, platform, or system from an accessibility perspective. Additions, corrections, or further thoughts are welcome in the comments.

Previous posts: HTML5 <video>, HTML5 Semantic Elements, New <input> Types in HTML5, HTML5 <input> Extensions, SVG.

HTML Canvas

The HTML <canvas> element provides a blank drawing surface via which web application authors can create advanced 2D graphical elements via scripting. In this sense it is similar to (and subject to the inevitable comparisons with) both Adobe’s ubiquitous Flash plugin and the other “advanced web graphics” technology, SVG. The former comparison is probably the better one, since canvas (plus javascript) is indeed capable of doing a fairly large subset of what Flash is popularly used for today.

Browser Support

The <canvas> element was first introduced by Apple almost six years ago, then implemented by Mozilla and Opera, and finally introduced into the HTML5 standard by the WHATWG. Microsoft remains the only major browser vendor not to support canvas at this time, and has neither committed to implement it nor officially specified that they have no intention of doing so; it is probably a safe bet that (barring a late-stage change of priorities or surprise announcement) canvas support will not be present in Internet Explorer 9 (their next major release), but it could easily find its way into version 10 or some other later release.

The lack of complete browser support will likely stall the widespread use of the <canvas> element on the open web. Part of this could be resolved via the explorercanvas project, an open source javascript library that adds canvas support to Internet Explorer via VML (an SVG-like vector graphics format supported only by them); another project, fxCanvas, is attempting to do the same thing using Flash. How either or these projects would deal with the yet-to-be-determined canvas accessibility features remains to be seen.

Accessibility

The HTML5 language specification contains the following note in its section on the <canvas> element:

“When authors use the canvas element, they must also provide content that, when presented to the user, conveys essentially the same function or purpose as the bitmap canvas. This content may be placed as content of the canvas element. The contents of the canvas element, if any, are the element’s fallback content.”

Generally speaking, “fallback content” (i.e., content included to benefit users whose web browsers don’t support a particular feature or format) are not appropriate as accessibility solutions because (to begin with) users with disabilities are likely to be using as modern and powerful browsers as anybody else. The case with canvas is similar; while some sort of DOM-based alternative content is a possible solution to canvas accessibility concerns, that won’t work without some modifications to the spec and/or canvas API.

Accessibility of what?

Solving the canvas accessibility problem is a bit tricky, largely because the <canvas> element (when combined with javascript) is essentially a mini-platform of its own, where just about anything is possible.

The official spec says only one thing about what the <canvas> element can or cannot be used for:

“Authors should not use the canvas element in a document when a more suitable element is available. For example, it is inappropriate to use a canvas element to render a page heading.”

This is a good thing because (as with SVG) emulating existing HTML elements in canvas is likely to result in a significant accessibility hit. But as long as web authors aren’t emulating existing HTML elements, any other use is allowed; more than that, the canvas spec was specifically designed to account for uses nobody has even thought of yet, it being merely a low-level drawing surface with no particular purpose or function in mind. This is what makes canvas so exciting as an addition to HTML, and so complicated from an accessibility perspective.

If one is merely using an HTML canvas to produce on-the-fly 2D graphics, simple alternative text (just like any other graphic in a web document) should provide sufficient accessibility. That’s the easy part. People using canvas to create animated web comics might need some sort of synchronized caption or description capabilities, similar to what’s being developed for the <video> element. That one’s a bit harder, but doable. Then there’s the statistical charts, various games and puzzles, fun physics simulations, drawing applications, and more. (And those are just the things people have built so far.)

Because canvas apps can be so drastically varied in form and function, canvas accessibility is in a sense different for every project. Some use-cases could easily be made completely accessible, while other projects might require a significant amount of work to get accessibility right, while in still other cases full accessibility might not even be possible. Additionally, many of the principles and techniques required to do make canvas apps accessible will more closely match those used for traditional (i.e., desktop) application accessibility, rather than web accessibility as we usually think of it.

This probably explains why the canvas accessibility situation hasn’t been figured out yet (and therefore isn’t really mentioned in the specification language).

Proposed Solutions

As with the HTML5 <video> element, the fact that there aren’t any accessibility features right now doesn’t mean there won’t be soon. Lots of very smart people are working on coming up with a solution, so we can probably safely assume that they’ll figure something useful out at some point. (The W3C isn’t in the habit of giving themselves deadlines, so when exactly that might happen is anybody’s guess.) As of recently, there were two main proposals being discussed, one that involves the concept of an accessible “shadow DOM” and one involving a beefed-up version of the client-side image map. (Somebody involved with the discussion can feel free to correct me in the comments if I get this horribly wrong.)

The shadow DOM concept would provide a canvas alternative via a tree of equivalent elements “underneath” the visual canvas. Essentially, this would make canvas an exception to the rule discussed above, so that an accessible alternative could be included as descendants of the <canvas> element. This would help assistive technology users interact with the canvas content, though it is unclear to me how other users (such as those navigating with only the keyboard) would access the fallback DOM.

The image map solution involves allowing the usemap attribute on canvases, then allowing any element in the DOM to serve as an image map area (as opposed to the area elements used currently). This way an actual button element could be created in the DOM (but possibly hidden from view) and attached to a certain pixel region of a canvas (where a clickable area exists in the canvas application), in the which case the latter region would be keyboard focusable and announced to assistive technologies as if it were an actual (i.e., the actual) html button, with all the flexibility and accessibility that that allows.

Other proposals currently or previously discussed involve extending the canvas javascript API to allow developers to programmatically make certain areas focusable, or provide alternative text to them.

An Opportunity

All of the canvas accessibility solutions discussed in the previous section have one thing in common: they all require some nontrivial work on the part of the developer in order to make accessibility happen. This is, of course, unavoidable, since only the author knows for sure what something is supposed to mean or represent. However, it’s important that we make the solution as simple and easy to both understand and implement as possible, in order to get as many developers as we can to actually use it.

These days, most advanced graphical web applets are created using Adobe’s Flash plugin, and are not typically very accessible. Adobe developers are quick to point out that there is nothing intrinsically inaccessible about Flash itself: accessibility support exists for almost everything, but for one reason or another most flash developers don’t take advantage of these features, and the result is a web overflowing with inaccessible flash apps.

Although Flash isn’t going away any time soon, people are right to expect that much of what is currently being developed with Flash will soon migrate to canvas/javascript systems. With this transition there is an amazing opportunity to make sure that things are done right the second time around. If the eventual accessible canvas solution is flexible enough to handle the multitude of possible canvas uses, yet simple and “normal feeling” enough to get large numbers of developers to use it, it will be a huge gain for global web accessibility as a whole. If that doesn’t happen, then I suppose we won’t be in any worse of a situation than we are right now, but we’ll have missed a big opportunity that could have made a serious positive difference.

The Bottom Line

HTML canvas really neat, but sadly held up by a lack of support in IE. No current accessibility features. Work undergoing to add them.

Further Reading

• Canvas element – Wikipedia [wikipedia.org]
• The canvas element – HTML5 [whatwg.org]
• Let’s Call It A Draw(ing Surface) – Dive Into HTML5 [diveintohtml5.org]
• Canvas – HTML Accessibility Task Force Wiki [w3.org]
• Canvas Element Accessibility Issues – HTML WG Wiki [w3.org]
• ISSUE-74: How accessibility works for <canvas> is unclear [w3.org]
• Thinking About HTML 5 canvas Accessibility [paciellogroup.com]