Re: Canvas as input vs. img (was Using @aria-describedby for long described image links [Was: Using an image map for long described image links [Was: Revert Request]])

I'm going to follow-up on this particular thread -- Canvas usage 
categories, on public-canvas-api.
But, for this reply, it's in-thread.


On 2/7/2012 4:32 PM, Frank Olivier wrote:
> IMO all canvas usage can be categorized as
>
> 0 - Decorative use - no actual information is communicated

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.
WebKit introduced a CSS Canvas context for these kinds of cases, to be 
deprecated eventually by the element() css selector.

> (Example:http://ie.microsoft.com/testdrive/Performance/ParticleAcceleration/  )

0. Decorative use, image asset generation.
1. Basic media.

This as an example of 1a. Benchmarking demos.
They are intended solely for developers: coding experiments, sometimes 
interactive.

Here's a bunch more:
http://js1k.com/2012-love/demos

They cross over into example 1b. Video demos.
http://www.xanthir.com/blog/b46e0
https://developer.mozilla.org/En/Manipulating_video_using_canvas

They lead into 1c.

> 1 - Non-interactive canvas - 'read-only' information
> (Example: Drawing a scatterplot + associated labels in canvas; this has always been possible via server-side generated<img>.)

This does not meet the bar set by WCAG. A scatter plot is going to have 
interactivity; the labels should be made available.
Server-side generated <img> graphics will have image maps. A 
non-interactive Canvas is by definition, for decorative use.

1c. Basic media implementations.
http://libwebpjs.hohenlimburg.org/vp8/webm-javascript-decoder/
http://webpjs.appspot.com/

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.

Items 0 and 1 fit between <img>  and <video>-centric uses of Canvas.

> 2 - Interactive canvas - 'user interfaces'

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.

2. User interface components
> 2a Simple single controls - a single checkbox, button, etc (a single<input>  element in the canvas sub-tree)

2a. 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.

Otherwise, it's not that frequent. Note, these are Basic Element 
implementations.
It's debatable whether Image replacement techniques fall into Category 
0: Decorative use, or Category 2a: Basic Elements.
http://en.wikipedia.org/wiki/Fahrner_Image_Replacement

> 2b Sometimes more complex things like spline editors (iow multiple<input>  elements/tab stops/focusable areas in the sub-tree)

2b. Composite Elements.

Implementations of elements with multiple control types, such as a 
<select> button.

2c. Complex multimedia implementations.

These implementations are often based on existing formats, such as PDF, 
SVG or HTML4 Forms.

3. Ink Surfaces

Using input from a pointer device or other CAD technique, these provide 
a full surface for rendering and editing.



-Charles

Received on Thursday, 9 February 2012 21:42:18 UTC