[Bug 10248] Canvas requires a Caret Drawing call method

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