- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Fri, 10 Jul 2009 16:18:39 +0300
- To: joshue.oconnor@cfit.ie
- Cc: HTMLWG WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
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:23 UTC