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 missed one more item:

4. 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.




On 2/9/2012 1:41 PM, Charles Pritchard wrote:
> 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:49:31 UTC