- From: <bugzilla@wiggum.w3.org>
- Date: Fri, 26 Jun 2009 21:05:14 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7011 --- Comment #14 from Ian 'Hixie' Hickson <ian@hixie.ch> 2009-06-26 21:05:14 --- > by giving it some thought and proposing some way to add the info required for > accessibility, to content in canvas. As far as I can tell, what the spec currently suggests is a pretty good solution to this. Basically it suggests generating a DOM tree (would could e.g. use ARIA roles if that is necessary) inside the <canvas>, exactly as Simon demonstrates above. > I suggested a crude idea of mapping area elements to focusable areas on a > canvas, which could have aria roles and states added to represent the many > interface elements that authors may develop using canvas. This seems equivalent to just including focusable areas as descendants of the <canvas> element, optionally with ARIA roles and states (or alternatively just using native HTML semantics like links and form controls). > Another issue that comes to mind in relation to the current canvas fallback is > that for any duplicate fallback that includes event handlers, there are going > to be interaction issues between those event handlers on the canvas and > those on the fallback. there is no mention of this currently, there needs to be > a robust method specified to resolve this. Could you elaborate on this? I don't understand. A user agent would presumably have the user interact with only one or the other, not both. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Friday, 26 June 2009 21:05:28 UTC