- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Wed, 5 Aug 2009 15:46:59 +0300
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- Cc: HTMLWG WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
On Jul 30, 2009, at 15:50, Richard Schwerdtfeger wrote: > I have been following a number of threads and I think you can agree > that, although the HTML working group has stated that canvas should > only be used for drawings, authors will do what they want. It is > just a fact of life. > > In order to make canvas accessible we will need: > • An object model to which authors can apply an accessibility API. This already exists on the spec level (well, maybe not so clearly for focus traversal) in the heavy-weight (object is a DOM node) form: Putting an ARIA-decorated DOM subtree inside <canvas>. I doubt the benefit of speccing another object model. A new object model could perform a bit better that a DOM subtree but any object model would still be an abstraction level mismatch with the Canvas 2D API. > • A collection of callback interfaces that can be applied to > objects to support an accessibility API mapping on each browser and > platform and potentially a vehicle to fire events to ATs. It seems to me that this is the approach that matches the level of abstraction that the Canvas 2D API provides if one considers what kind of desktop environment native APIs are being replicated on the Open Web Platform. Two issue come to mind: * An IPC mechanism can't call into JavaScript concurrently. Instead, there needs to be a mechanism that schedules calls to the JS- implemented interfaces on a task queue. (Maybe this is already a solved problem considering the single-threaded nature of the DOM.) * If the mapping from low-level platform APIs to a JS API is direct, malicious or incompetently written scripts can tell AT crazy things. Are ATs robust against apps telling them crazy things? Does the browser need to be able to sanitize the interaction instead of directly mapping the interfaces? > • A provision for equivalent alternative references that allow a > canvas author to specify an alternative resource for drawing that > cannot be made accessible through traditional API. On the spec level, this mode of accessibility is already supported by inclusion rather than by reference by allowing <canvas> to hold a DOM subtree of alternative content. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Wednesday, 5 August 2009 12:47:41 UTC