This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Per Issue 74, we need an API that will draw a focus ring based on system conventions and the current focus location in the <canvas> DOM subtree that is independent caret and selection tracking that will support driving a screen magnifier based on the screen location and corresponding <canvas> subtree element semantics.
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.
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: Accepted Change Description: no spec change Rationale: drawFocusRing() seems to provide this, unless I've misunderstood comment 0.
We have a revision to drawFocusRing we would like to submit for review in response to this defect. We are waiting on group consensus from the canvas accessibility sub team.
I have reopened this so that a change proposal can be submitted.
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/WORKSFORME 2) Adding TrackerIssue keyword 3) Moving to pre-LC component, since this is covered by a pre-LC issue resulting from older bugs
mass-move component to LC1