This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 11240 - Canvas support accessible selection position tracking independent of Focus Ring tracking
Summary: Canvas support accessible selection position tracking independent of Focus Ri...
Status: RESOLVED WONTFIX
Alias: None
Product: HTML.next
Classification: Unclassified
Component: default (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, a11ytf, a11y_canvas, TrackerIssue
Depends on: 10964
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-05 20:21 UTC by Rich Schwerdtfeger
Modified: 2012-11-15 21:12 UTC (History)
9 users (show)

See Also:


Attachments

Description Rich Schwerdtfeger 2010-11-05 20:21:25 UTC
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.
Comment 1 Maciej Stachowiak 2010-11-08 08:05:10 UTC
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
Comment 2 Michael Cooper 2010-11-30 16:41:11 UTC
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.
Comment 3 Ian 'Hixie' Hickson 2011-01-10 23:38:50 UTC
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.
Comment 4 Rich Schwerdtfeger 2011-01-11 00:31:38 UTC
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.
Comment 5 Maciej Stachowiak 2011-01-11 19:40:29 UTC
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
Comment 6 Michael[tm] Smith 2011-08-04 05:03:24 UTC
mass-move component to LC1
Comment 7 Michael[tm] Smith 2011-12-15 16:42:14 UTC
We discussed this on the a11y TF call and agree with Maciej's assessment in comment #5.
Comment 8 LĂ©onie Watson 2012-11-15 21:12:49 UTC
Moved to HTML.Next on request of Rich Schwerdtfeger.