- From: Cameron McCormack <cam@mcc.id.au>
- Date: Thu, 7 Jul 2011 12:01:49 +1200
- To: Charles Pritchard <chuck@jumis.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, Charles McCathieNevile <chaals@opera.com>, Henri Sivonen <hsivonen@iki.fi>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, public-canvas-api-request@w3.org, "public-html@w3.org" <public-html@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
Charles Pritchard: > We've made progress on keyboard events via drawFocusRing and the > shadow dom with the existing canvas 2d context. I don't see why > pointer events warrant forking to a completely new context. I don’t think need to invent a whole retained mode version of <canvas> or a new context. We’re not solving all accessibility problems with <canvas> here. For the general problem of making arbitrary graphical content accessible I agree we should encourage the use of SVG and improve SVG’s accessibility. Here is how I see the problem at hand: * we are drawing HTML form/UI control like content to the <canvas> * we have a subtree of the <canvas> that contains the form elements which have funky presentation on the <canvas> * the subtree elements are used to manage focus * magnifiers need to know the bounds of the currently focussed element so that the screen can be zoomed to it * the actual form elements in the subtree aren’t being rendered, so we can’t use their bounds to give to the accessibility APIs * we need to inform the magnifier of the bounds of the currently focussed element Since we are already using the subtree elements to represent the accessible version of the <canvas> content, it makes sense to associate the subtree elements with the region of the <canvas> that represents them. In this situation authors are already committed to creating and maintaining the <canvas> subtree to make their application accessible. It seems to me that the simplest solution, as I mentioned in another branch of the thread, is to annotate the subtree element with the region on the <canvas> that is being used to represent it, using a DOM attribute aria-region="" or something. The reason why I think it is feasible to require setting an attribute explicitly and not to have the association done automatically because of calls made on the canvas context is that the author already must maintain the subtree manually. A question: do mangifiers just need a rectangle or do they need a general path? Can someone point me to the APIs that would be used by the implementation to communicate the currently focussed region? -- Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 7 July 2011 00:02:47 UTC