11240 2010-11-05 20:21:25 +0000 Canvas support accessible selection position tracking independent of Focus Ring tracking 2012-11-15 21:12:49 +0000 1 1 1 Unclassified HTML.next default unspecified PC All RESOLVED WONTFIX a11y, a11ytf, a11y_canvas, TrackerIssue P2 normal --- 10964 1 schwer ian ian laura.lee.carlson lwatson mike mjs public-html-a11y public-html-admin public-html-wg-issue-tracking robin public-html-bugzilla oldest_to_newest 42205 0 schwer 2010-11-05 20:21:25 +0000 Per Issue 74, we need an API that will let a magnifer be notified of selection point screen location changes in response to editable text form elements in the Canvas DOM sub tree. 42235 1 mjs 2010-11-08 08:05:10 +0000 Moving to LC component since this did not make the pre-LC cutoff. (Feel free to request an exemption from the chairs if there are good grounds. But this also seems to be already covered by ISSUE-131: http://www.w3.org/html/wg/tracker/issues/131 42906 2 cooper 2010-11-30 16:41:11 +0000 Bug triage sub-team thinks this bug is providing additional details on 10964, which was raised just at the Last Call cutoff deadline with the understanding that more precise information would be filed later. This bug constitutes part of that information and therefore we think this should be considered a pre-LC bug. Also note that this bug relates to ISSUE-131 http://www.w3.org/html/wg/tracker/issues/131 and arguably ISSUE-74 http://www.w3.org/html/wg/tracker/issues/74. 44057 3 ian 2011-01-10 23:38:50 +0000 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: Rejected Change Description: no spec change Rationale: I've rejected this proposal on the following multiple independent grounds: * I couldn't come up with an API that enough people would use correctly to justify having the feature. If we have this feature, we need to have some sort of API that essentially acts like a trojan horse, providing a feature for authors to use while surreptitiously providing the a11y feature. In other words, it needs to not be bolt-on accessibility. This is, for example, the reasoning behind the design of <nav>, of <input type=date>, of drawFocusRing(), and so on: they provide legitimate features that authors will want to use and will likely use correctly, with which we can _also_ provide accessibility features (e.g. skipping navigation, native accessible date controls, magnification following, etc). Historically, APIs designed exclusively for accessibility have been a disaster, with most authors ignoring them, and the remaining authors trying to use them but failing due to lack of testing or understanding, with the end result being a net harm to accessibility. * Editing text is not something that we should encourage authors to do using <canvas>. This is true regardless of accessibility concerns — many native features get lost in such an implementation. * Selections are not points, they are non-rectangular disjoint regions, and their precise rendering varies from platform to platform in ways that would make such an API difficult to provide. (e.g. on Mac a selection of two lines each containing one character spans the width of the container, whereas on Windows it only spans the width of the characters) * No user agent vendor has indicated an interest in implementing this feature. 44067 4 schwer 2011-01-11 00:31:38 +0000 I would prefer that the group working on this reach consensus before it is closed by someone not involved in the work. We will need the ability to track the caret whether rich text editing is supported in canvas or not. People who create a canvas application may wish to create text fields to adjust the parameters controlling what is drawn on canvas. Although this is doable from standard HTML form controls. We also have the major screen magnifier on Windows (AISquared) engaged in the discussions. 44201 5 mjs 2011-01-11 19:40:29 +0000 Richard, it seems this bug is already covered by ISSUE-131: http://www.w3.org/html/wg/tracker/issues/131 More generally, if the editor has given a disposition and someone else wants to provide new information in the future, it's correct for the bug to stay resolved in the meantime. For these reasons, I'm making the following changes: 1) Moving bug back to RESOLVED/WONTFIX 2) Adding TrackerIssue keyword 3) Moving to pre-LC component, since this is covered by a pre-LC issue resulting from older bugs 52650 6 mike 2011-08-04 05:03:24 +0000 mass-move component to LC1 61613 7 mike 2011-12-15 16:42:14 +0000 We discussed this on the a11y TF call and agree with Maciej's assessment in comment #5. 78373 8 lwatson 2012-11-15 21:12:49 +0000 Moved to HTML.Next on request of Rich Schwerdtfeger.