Re: another example of HTMl 5 canvas with interactive UI elements.

On Jul 10, 2009, at 12:18, Joshue O Connor wrote:

> That could become the spec equivalent of "Cigarettes may damage your
> health" - in other words redundant verbiage that may as well say  
> "Smoke
> 'em if you got 'em".

Indeed.

> FWIW <canvas> is really interesting for what it
> does - and I have seen some clever things done with it - it is just  
> very
> flawed (in terms of inherent semantics) and these flaws could  
> seriously
> effect PWDs who will not be able to access <canvas> content at all
> without some committed developer magic, care and attention.

Well, <canvas> is as flawed as Cairo or Quartz 2D. It's not a high- 
level retained mode API, so it's can't be inherently accessible. Even  
if we had an API for managing keyboard focus inside <canvas> and  
another API for letting JS represent non-DOM-based accessible subtrees  
trees of <canvas> to AT, accessibility would still depend on the  
developers bothering to use those APIs. By its low-level nature,  
<canvas> is doomed to bolt-on accessibility.

Aside: The retained-mode accessibility solution already exists,  
although I don't know how buggy it is in practice: Putting a DOM  
subtree potentially with ARIA attributes into <canvas> content.  
However, to a large extent this defeats the point of having an  
immediate-mode graphics API. If the developers were OK with retained  
mode, they might as well use SVG+ARIA.

> If the
> solution ain't elegant then the examples in the wild that we will be
> looking at in a few years time to support the retention of <canvas> in
> HTML 6 will be pretty poor...sound familiar?


I don't think it's realistic to try to put a lid on this box. <canvas>  
is out there and there will be inaccessible uses even if an  
accompanying accessibility solution were available. :-(

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Friday, 10 July 2009 13:19:21 UTC