[CEUD-ICT] <canvas>: the Flash Killer? (was Joe Clark on the (technical) future of e-books...)

[Joshue O Connor]

Hi Barry,

On 11/03/2010 17:34, Barry McMullin wrote:
> On Thu, 11 Mar 2010, Donal J. Rice wrote:
>
>> What's confusing me at the moment is all this talk of the iPad not
>> supporting flash which some people say will be replaced in time by HTML 5.
>> Having never really caught onto why we needed a HTML 5, (isn't XHTML
>> perfectly fine) inspite of Josh's extensive reporting of it on this list, I
>> am beginning to think HTML 5 is not the animal I thought it was. Surely
>> these are 2 completely different types of technology.  Can HTML 5 render
>> images and animation the same way flash does?
>
> In a nutshell: the HTML5 draft includes a new "canvas" element
> that provides much of the basic functionality that flash is often
> deployed for.  Perhaps more important than its mention in a mere
> draft of anything, canvas is actually already supported, out of
> the box, by recent versions of Firefox, Chrome, Safari, and
> Opera.

What is interesting is that there isn't a direct one to one mapping 
between the <canvas> API in HTML 5 and Flash. Flash is, at this stage, 
far more advanced. In terms of accessibility <canvas> has a /long/ way 
to go - think Himalayan. This is because, natively, there just is not a 
lot to work with, as there is only a <canvas> element (and thats it). 
There are (AFAIK) a couple of primitives, or even just one (literally) 
but it operates pretty much like a vector based drawing tool (rather 
like Flash). Flash at least has a DOM, or tree that will allow a user to 
tab to elements via the keyboard, label controls etc. <canvas> has no 
such thing. It is (at the moment) purely visual. To make this accessible 
means adding a DOM (the a11y working group is looking at adding an aDom 
element at the moment) and various other, for want of a better word - 
hacks - to try and make it fly. [1] [2]

There is a sub group in HTML 5 that is working on the <canvas> a11y 
issue but I'm only peripherally involved with it (by choice).

So whats the problem, why can't <canvas> be accessible out of the box. 
Ian Hickson is very fond of posturing a stance on Universal Design and 
has been very critical of attributes like @summary as they /only/ serve 
the needs of blind users (rather well I may add) rather than everyone 
(use cases are also thin on the ground lol), but he missed a trick here. 
 From the ESW wiki we find the problem in a nutshell. [3]

"HTML5 currently lacks specific mechanisms to add accessibility hooks 
for content produced using this element. Traditionally, native 
development platforms provide some degree of automatic high-level 
accessibility support for built-in controls, and then a low-level 
accessibility API for custom controls that developers build using 
drawing primitives and events directly. The Web platform lacks something 
similar. For images that are generated on the fly, but thereafter not 
modified, a text alternative might suffice. For animated graphics demos, 
a description of the demo could be enough. But for truly interactive 
application-like content that is custom-rendered, a true accessibility 
API is needed, not just an assortment of different textual alternative."

The core of the problem, in my opinion, is that the element was designed 
without a DOM, or any kind of ability to add a tree beyond tacking it on 
at the end. This is what has happened and why there are so many 
potential problems. The development of the Bespin IDE being a case in 
point. It looks great, is a fantastic proof of concept for cool things 
you can do with <canvas> and is completely inaccessible. [4]

It is however, a good example of what can be done (and why shouldn't 
developers be allowed to built things) and there will be more. The spec 
does say, that <canvas> should not be used where there is a more 
suitable element (say to support accessibility a heading is given as an 
example) but its a little like saying to your cat, here is some Whiskas 
but don't eat it, and we can guess how that ends.

There are some great people getting behind the a11y effort with <canvas> 
(Rich S, Chaals, Steve F) but I think anything they come up with will be 
a hack as the <element> doesn't have any semantic rich media 
capabilities out of the box as it just wasn't designed with any.

May the force be with them

However, will <canvas> kill Flash? In the short term, no but given time 
- maybe. [5]

Cheers

Josh

[1] 
http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0250.html
[2] http://www.w3.org/html/wg/wiki/ChangeProposals/Map4NotAdom
[3] http://www.w3.org/html/wg/wiki/AddedElementCanvas
[4] https://mozillalabs.com/blog/2009/02/introducing-bespin/
[5] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#the-canvas-element




********************************************************************
National Council for the Blind of Ireland (NCBI) is a company 
limited by guarantee (registered in Ireland No. 26293) .
Our registered office is at Whitworth Road, Drumcondra, Dublin 9.
NCBI is also a registered Charity (chy4626). 

NOTICE: The information contained in this email and any attachments 
is confidential and may be privileged.  If you are not the intended 
recipient you should not use, disclose, distribute or copy any of 
the content of it or of any attachment; you are requested to notify 
the sender immediately of your receipt of the email and then to 
delete it and any attachments from your system.

NCBI endeavours to ensure that emails and any attachments generated 
by its staff are free from viruses or other contaminants.  However, 
it cannot accept any responsibility for any such which are 
transmitted.  We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email 
and any attachments are those of the author and do not necessarily 
represent the views of NCBI


********************************************************************