- From: Doug Schepers <schepers@w3.org>
- Date: Thu, 07 Jul 2011 13:18:37 -0400
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- CC: Richard Schwerdtfeger <schwer@us.ibm.com>, Charles Pritchard <chuck@jumis.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>
Hi, Benjamin, Rich- Benjamin Hawkes-Lewis wrote (on 7/7/11 11:53 AM): > On Thu, Jul 7, 2011 at 2:58 AM, Richard Schwerdtfeger<schwer@us.ibm.com> wrote: >> >> I agree. and title and description are insufficient for dynamically >> changing drawings. This is an SVG deficiency but NOT a canvas >> deficiency. Although important, the bounds of an object are only a >> piece of all the things to support interoperability. You need >> roles, relationships, state change notifications, and so on. We >> have those in canvas now. We do not in SVG. > > What roles, relationships, state change notifications are available in > HTML content that uses canvas that are not available in HTML content > that use SVG? None. This seems to be a misunderstanding of SVG. SVG, either in HTML or as a standalone document (or, for that matter, as part of the logical subtree of a <canvas> element), can have ARIA markup applied to it. SVG Tiny 1.2 even goes so far as to add @role explicitly for use with ARIA [1]. I asked the PFWG several times over the last 3-4 years to help work on specific ARIA roles, attributes, and values for SVG, knowing that accessible graphics are both important and difficult, but the response has been that they wanted to focus on HTML first. I understand that, but I don't support adding bolt-on solutions to the Canvas 2D API in exclusion of SVG, when it will ultimately be easier for both authors and accessibility vendors to work with the more advanced solutions that SVG is capable of providing for graphics. >> Let's stick to the problem at hand. ... canvas. Eventually we will >> get to SVG but not today. Canvas is part of HTML and it needs to be >> fixed. > > SVG is just as much a part of HTML as the canvas context, so I'm > confused by the implication that it's okay for us to fix any > accessibility problems with using canvas with HTML before we fix any > accessibility problems with using SVG with HTML. Correct. The <canvas> element is part of HTML5, but it does not mandate which APIs must (or can) be used with it. Neither the Canvas 2D API nor SVG, are technically part of the HTML spec, but both can be used with HTML in a manner defined by the HTML5 spec; we can (and plan to) equally define how the Canvas 2D API can be used with SVG as well as with the HTML <canvas> element. Rich, the Canvas 2D API is not part of HTML. Only the <canvas> element is, and there are separate APIs that can write to it, including (but not necessarily limited to) the Canvas 2D API and the WebGL API. [1] http://www.w3.org/TR/SVGTiny12/metadata.html#MetadataAttributes Regards- -Doug Schepers W3C Staff Contact, SVG, WebApps, Web Events, and Audio WGs
Received on Thursday, 7 July 2011 17:18:40 UTC