- From: <bugzilla@jessica.w3.org>
- Date: Sun, 26 Sep 2010 17:29:28 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10248 --- Comment #4 from Rich Schwerdtfeger <schwer@us.ibm.com> 2010-09-26 17:29:28 --- I would disagree with your statement Ian that accessibility APIs are largely ignored. Enterprises are required to support accessibility. The second point I disagree with is dismissing the issue just because you think it is stupid to create editors in canvas. Similar statements were made about applications in HTML 4 then along came Ajax and JavaScript and now they are used for web applications that 7 years later were made accessible using ARIA. In the meantime people can't do their jobs and they become unemployed. Now something you need to be aware of is that operating systems want to stop the use of graphics engine hooking that allows magnifiers to follow the caret this problem is extending to browsers where both IE and Firefox are pushing for direct draw techniques on Windows to do tracking. What you are advocating for is that magnifier vendors continue to reverse engineer an accessible alternative that is constantly subject to OS breakage. We need an engineered solution. Over time, and for security reasons and OS stability reasons, I don't think OS manufacturers are going to want to support this OS hooking strategy to track caret tracking. A while back you had asked that I simply write two defects against <canvas> to create a caret/selection and focus ring defect against Canvas 2D API vs. having a separate accessibility API set to drive magnification After we spoke on the WhatWg IRC channel you stated that this was not worth the effort. So, now we are at a standstill. What you are saying is there is not good solution that solves everything you would like. The reality is we may not get everything we need. For now I am perfectly willing to have an API that drives magnification as I think most accessibility people would. We have that in my proposal although there may be some tweeks we need to make. I sent James Graham a revised draft in response to his comments and have not heard back in a month. What we cannot do is shuffle this problem under the rug as some authors may created some form of text editor in <canvas>. So, if you actually believe that most authors are not going to create text editors in <canvas>, and in fact should not, why would we spend an enormous effort trying to make an API that draws and drive caret/selection/blink in a magnifier at the same time? I wanted to pass one more thing along. When I talked to IBM researchers about canvas and accessiblity the first thing out of their mouths was basically " this is great, we can use it to draw HTML controls. can you make that accessible?" This unfortunately is reality. -- 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, 26 September 2010 17:29:30 UTC