Decorative use includes asset generation. Gradients and the like. This is a good place to start, "decorative use" is defined in WCAG.
Typically, when procedurally generating such graphics, what we will do is use toDataURL and push them into an image or CSS.
It's the Canvas context that's most likely to be used here. It's often the case that we won't even put the canvas element into the DOM.
Decorative use, no information is communicated, paint server
WebKit introduced a CSS Canvas context for these kinds of cases, to be deprecated eventually by the element() css selector.
Basic media
Procedural demos
They are intended solely for developers: coding experiments, sometimes interactive.
It's been possible via server-side generated images to generate charts for some time; such charts should always have image maps or otherwise convey alternate navigation interfaces. Failing to do so is only appropriate for charts that are for decorative use or otherwise solely exist to visually augment data presented to the user in text and accessible via the DOM.
Drawing a scatterplot or other graph without associating the labels in the DOM is a failure of accessibility.
Basic media implementations
These are real libraries meant for actual consumption. These do not truly fit in the concept of "decorative" use. They are content-based. They may or may not have associated form elements. Implementations may also include SVG filter chians.
They ought to have some interactivity, in some cases, such as displaying loading error information, or a pause button if animated. However, instances of these items may span from the most basic category of presentation or decorative use to more advanced categories of basic and component elements.
With an interactive Canvas, the author should be using the DOM to convey UI information.
The Canvas will be present in the DOM, it should have title, id and/or ARIA information. Title is not particularly reliable, and so it's highly recommended that ARIA is used as well as semantic HTML.
Basic Elements
Gradient pickers are the most common place to encounter simple controls. Essentially, implementations of input @type="color" as well as combinations (for gradients).
input @type="range" is another common one to encounter.
Composite Elements
Implementations of elements with multiple control types, such as a select button, a set of radio buttons or other collection of form elements.
Complex multimedia implementations
These implementations are often based on existing formats, such as PDF, SVG or HTML4 Forms.
Using input from a pointer device or other CAD technique, these provide a full surface for rendering and editing.
Vector editors and other spatially oriented components.
Raw paint surface
This is most frequently used for emulators and cross-compiled applications. There are gameboy emulators for instance.
There are implementations of Java that run in JavaScript. There are implementations of Flash.
There is an implementation of LLVM. There are VNC implementations.
These are similar to item 2c. Complex multimedia implementations.
The distinction, though, is that the author is likely to be using proxy methods, implementing a pre-existing 2d graphics API atop Canvas.
They may, for instance, implement flash.display.* or Windows.Drawing.
With something like VNC, they may be implementing an accessibility tree atop the VNC protocol.
Work with LLVM has demonstrated that old applications not built for the browser can be run in the browser.
Google has the PNaCl project, running those applications in native code. Mozilla has the Emscripten route, running the native code in the JS virtual machine.
Authors have repeatedly and successfully used Emscripten with Canvas to run old applications in the browser without plugins.
"CSS3 won't even be fully standardised until 2008 if things carry on as they are, I wouldn't count on widespread support any time soon, unfortunately."
Ben Basson - December 23rd, 2005
Canvas may be supported on legacy platforms through the use of plugins. Add all instances of Canvas elements to the DOM to ensure that the Canvas rendering context can be initialized on these platforms. These elements should be added with their display set to none, so as not to interfere with rendering. They may be nested inside of a pre-loaded canvas context.
In some environments, scripting may be disabled or otherwise deficient for Canvas rendering. Authors must use progressive enhancement to ensure the best result for their users.
Create a path to disable Canvas content. This is useful for development, and may be useful to some users. Many browsers do not have an easy means of disabling Canvas content. Some do. You may use simple flags to stop your scripts from running Canvas content, and may also use the flags to pull fallback content out of Canvas elements.
The Canvas sub-tree, often referred to as the Canvas fallback content, should include sufficient information for audiences to interact with the page through eyes-free interfaces. Use best-practice techniques with Semantic HTML and ARIA.
Content included in the Canvas should be made available to the DOM when practical. This ensures that DOM based services, such as translation services and text to speech services are able to access underlying content. Use the DOM nodes to draw content, instead of hard-coding the content into the scripting environment.
Canvas Usage Tests and Examples
These examples are designed for browsers which have implemented Canvas accessibility hooks. They contain some fallback code, but for brevity, do not contain the full mechanisms listed in Canvas Techniques.
This demonstrates a simple Canvas that routes all clicks to a button contained in its sub-tree. Users should be able to navigate to the button through normal focus and keyboard navigation.
This demonstrates multiple checkboxes contained in one Canvas element. Because multiple elements are contained in one Canvas sub-tree, the author must implement focus management for accessibility. At present, spatial accessibility is under discussion. This example uses the proposed addEventTarget extension in addition to using fallback techniques for browsers that do not implement addEventTarget for pointer events.
Canvas is a low level API and requires manual management of all interactivity.
The following example is quite verbose, and demonstrates the minimum of programming
necessary to enable a simple checkbox element within canvas assuming that keyboard focus management is supported by the browser.
