This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This is related to Issue 74. Currently, the HTML accessibility task force is proposing an API that authors would use to report the caret location to a browser when editing text. This would be used by the user agent to support accessibility services to drive magnification. This approach requires an additional work by the author. It would be better if the author have a method to draw a caret where the ability to drive magnification would be handled under the covers. As a minimum the new method should take an element that pertains to the element having the caret in the fallback content or if Charles McCathieneville's proposal is accepted an element in an area map. It must be possible for the user agent to assess the coordinates used to draw the caret. This can be done by either using the drawing path or by passing a rectangle with coordinates. Carets often very in width and style. For example, they may be drawn using with a blinking rectangle that inverts the fill area of the rectangle. The severity is marked as normal. However if the proposed caretselectionrect function is not adopted as as part of Issue 74. This becomes a blocker.
This caret drawing method must accommodate blink rate limits for the OS the user agent is operating on.
http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0013.html The bug triage sub-team recommends the accessibility task force follow this.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: no spec change Rationale: To do this, we need to first come up with an API that would be used enough for this to be worth the cost, and would be used correctly more often than used incorrectly. Since purely accessibility-driven APIs are generally ignored by authors, we need a stalking horse to get authors to use this API (much as the focus ring drawing API is a stalking horse for getting the bounding box of the control in the first place). The obvious stalking horse here is "draw a caret". Unfortunately, I have not been able to come up with an API that (a) satisfies the accessibility use cases (blinks according to the system rate, draws the caret at the OS-set caret width, etc), (b) is sanely usable (handles clipping around the edge of a control, handles scrolling of a long text control in a small field, etc), and (c) is easier than just hand-rolling a custom caret painter. Without something that satisfies all three of these requirements, I don't think it makes sense to make an API available — it would actually be a net _negative_ to accessibility since people would likely use it wrong more often than they use it right, if they used it at all. So I am marking this NEEDSINFO: the need is for an API that satisfies these constraints. In practice it may make more sense to stop people from wasting their time writing editors in <canvas>, which is not what <canvas> was for, and indeed makes little to no sense. Trying to provide a caret API just justifies people doing this. It would be like providing a way for people to say what the semantic of a <blockquote> was, so that they could keep using it to indent text, while still in theory being able to make ATs act correctly. Note also that on some platforms, in particular Windows, many ATs actually do caret tracking by doing image analysis of the display to find where the blinking caret is, because so many applications hand-roll their own carets in an inaccessible fashion. So this might not be a huge problem in many cases.
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.
Has been escalated in ISSUE 131