- From: <bugzilla@wiggum.w3.org>
- Date: Sun, 28 Jun 2009 12:02:11 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7011 --- Comment #18 from steve faulkner <faulkner.steve@gmail.com> 2009-06-28 12:02:10 --- in reply to http://lists.w3.org/Archives/Public/wai-xtech/2009Jun/0093.html I would suggest 3 things: 1. For a problem that has stumped you we need as much technical expertise as is possible, so have included the HTML WG in this email. 2. we use an example that embodies the problem: http://people.mozilla.com/~jdicarlo/piemenus.html contains 2 examples of UI controls rendered using canvas. 3. rephrase the question: what would need to be added to the canvas API so that the UI controls in the example could have programmtic focus (like an area on an image map) and name, role and state information exposed to accessibility APIs, without expecting the author to completely recreate the UI controls in HTML. http://lists.w3.org/Archives/Public/public-html/2009Jun/0761.html http://lists.w3.org/Archives/Public/public-html/2009Jun/0762.html (In reply to comment #16) > (In reply to comment #15) > > what you are putting forward as 'a pretty good solution' is the antithesis of > > 'built in' accessibility. it asks the developer to duplicate the effort in > > creating content, it will also be 'hidden content' likely to become out of sync > > with the canvas based functionality. > > Agreed. > > > > if canvas is to be used , as it is already, to create UI elements, then it > > requires some 'built in' not 'bolt on' methods to ensure that name,role and > > state information of the interactive elements is available to assistive > > technology. > > I don't know how to do that. I'll contact the PFWG and see if they have any > advice. > -- 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 Sunday, 28 June 2009 12:02:24 UTC