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 8722 - focus behaviour should be same for canvas regions as for elements
Summary: focus behaviour should be same for canvas regions as for elements
Status: CLOSED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML Canvas 2D Context (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Rich Schwerdtfeger
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, a11ytf, a11y_canvas, NE
Depends on: 10248 10249
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-12 11:01 UTC by steve faulkner
Modified: 2012-11-15 17:14 UTC (History)
8 users (show)

See Also:


Attachments

Description steve faulkner 2010-01-12 11:01:58 UTC
currently the spec says:
3.Optionally, inform the user that the focus is at the given (transformed) coordinate on the canvas. (For example, this could involve moving the user's magnification tool.)[http://dev.w3.org/html5/spec/the-canvas-element.html#focus-management-0]

this should not be an option, the current focus needs to move in to the viewport the same way that it does for every other focusable element.
Comment 1 Ian 'Hixie' Hickson 2010-02-06 10:46:38 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: Even if the user doesn't want it to?
Comment 2 steve faulkner 2010-02-06 19:36:14 UTC
(In reply to comment #1)
> 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: Even if the user doesn't want it to?
> 

hi ian,
i don't think this is an adequate rationale, in fact i don't think it's a rationale, it's a question.
Anyway can you elaborate on the situations, or even a single situation where a user who is navigating through the focusable elements on the page would NOT want the currently focused element to be visible? 

note: I am considering 'element' as including the focus rectangles that are associated with elements inside the canvas tag.
Comment 3 Michael Cooper 2010-02-11 17:18:29 UTC
The HTML Accessibility Task Force intends to track these issues, per the proposal at http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0245.html.
Comment 4 Ian 'Hixie' Hickson 2010-02-17 11:56:00 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: Did Not Understand Request
Change Description: no spec change
Rationale: looking for further clarification

Suppose an AT allowed the user to make the focus track the mouse pointer, or follow the keyboard focus, and that the user could switch from one to the other. (This may or may not be a good idea, that's rather academic. There could be one user who prefers this, in which case he might write such an AT himself.)

Given such a situation, do you think the user agent would have to be defined as _non-conforming_ if it respected that user option, and _didn't_ move the magnifier when the user was in the "follow mouse" mode rather than the "follow focus" mode?
Comment 5 Maciej Stachowiak 2010-02-17 12:00:03 UTC
For what it's worth, VoiceOver does have a mode where the VoiceOver cursor follows the mouse. Though I do not know offhand if there is a magnifier that follows the VoiceOver focus.

However, it does seem that whatever is done should be consistent between focus of a real control and focus of a canvas region. So perhaps there should be a statement there that whatever in terms of announcing the focus location should be consistent with with the behavior for a real form control.
Comment 6 steve faulkner 2010-02-17 12:26:09 UTC
(In reply to comment #4)
> 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: Did Not Understand Request
> Change Description: no spec change
> Rationale: looking for further clarification
> Suppose an AT allowed the user to make the focus track the mouse pointer, or
> follow the keyboard focus, and that the user could switch from one to the
> other. (This may or may not be a good idea, that's rather academic. There could
> be one user who prefers this, in which case he might write such an AT himself.)
> Given such a situation, do you think the user agent would have to be defined as
> _non-conforming_ if it respected that user option, and _didn't_ move the
> magnifier when the user was in the "follow mouse" mode rather than the "follow
> focus" mode?

take the AT out of the example:
I am using a browser, as I tab through focusable elements the focus moves to the next element , if that element is out of view before it receieves focus, it gets moved into view. This is the behaviour for all browsers I have tried. Why should this not be the same for focusable elements on the canvas? where is it specified for other elements that this behaviour is optional?
Comment 7 Ian 'Hixie' Hickson 2010-02-17 20:11:00 UTC
Whether the UA actually moves focused elements into view or not without an AT is in fact completely at the whim of the UA  the spec doesn't even give a "may" for that. (If you think it should, please file another bug  I think it would be reasonable to explicitly allow that.)

As a user, if I wanted to move focus around without the page scrolling, e.g. because I happen to know the page's design and I want to be looking at the top of the page while tabbing to controls under the fold, I don't see why my user agent should be non-conforming if it gives me that option.

Generally speaking, everything in the UI is optional. The user agent is the _user_ agent, not the author agent. It's supposed to do whatever the _user_ wants. This means that pretty much any user interface feature is optional. Heck, the entire rendering section is optional.


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: making this a "may" is consistent with the best interests of users and consistent with all other user interface requirements in the spec.
Comment 8 steve faulkner 2010-02-18 09:34:27 UTC
hi ian, 

I will try to ask/explain it from a different perspective then.
Unless a focus event is recognized by AT, at the co-ordinates of the focus rectangle drawn on the canvas, then AT will not be able to move focus to the rectangle as it effectively has no meaning other than a being a shape on the canvas. I understand that a focus event can be flagged by the use of standard APIs. Does the the spec currently require/recommend that such an event flag occurs when the focus rectangle is drawn? If not why not? 





(In reply to comment #7)
> Whether the UA actually moves focused elements into view or not without an AT
> is in fact completely at the whim of the UA  the spec doesn't even give a
> "may" for that. (If you think it should, please file another bug  I think it
> would be reasonable to explicitly allow that.)
> As a user, if I wanted to move focus around without the page scrolling, e.g.
> because I happen to know the page's design and I want to be looking at the top
> of the page while tabbing to controls under the fold, I don't see why my user
> agent should be non-conforming if it gives me that option.
> Generally speaking, everything in the UI is optional. The user agent is the
> _user_ agent, not the author agent. It's supposed to do whatever the _user_
> wants. This means that pretty much any user interface feature is optional.
> Heck, the entire rendering section is optional.
> 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: making this a "may" is consistent with the best interests of users
> and consistent with all other user interface requirements in the spec.

Comment 9 Ian 'Hixie' Hickson 2010-02-25 02:37:50 UTC
I have no idea what this means.

> Unless a focus event is recognized by AT,

Do you mean a 'focus' event, a focus request by the user, a change of focus, a call to element.focus(), a call to window.focus(), or something else?


> at the co-ordinates of the focus rectangle drawn on the canvas,

Do you mean a focus rectangle drawn by drawFocusRing(), a focus rectangle drawn by script, or a focus rectangle drawn by a UA rendering a focus rectangle around an actual control?


> then AT will not be able to move focus to the rectangle

By "move focus" do you mean the magnification focus? The OS focus? The UA focus? The JS/DOM/CSS focus? Some other focus?


> as it effectively has no meaning other than a being a shape on the canvas.
> I understand that a focus event can be flagged by the use of standard
> APIs.

Do you mean OS APIs? AT APIs? ARIA? The canvas 2D APIs?


> Does the the spec currently require/recommend that such an event flag
> occurs when the focus rectangle is drawn? If not why not? 

I have no idea what this question means.


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: Did Not Understand Request
Change Description: no spec change
Rationale: I don't understand. Could you elaborate?
Comment 10 steve faulkner 2010-03-04 12:33:47 UTC
(In reply to comment #9)
Apologies that my lack of technical chops results in unclear requests. Rich S has provided spec ready text that resolves the issues I was trying to convey (unsuccessfully).

I have written up a change proposal for it:
Provide implementation information required for accessibility in the Canvas 2d Context specification http://www.w3.org/html/wg/wiki/ChangeProposals/canvasaccessibility

The spec ready text (also linked from the change proposal):
http://www.paciellogroup.com/blog/misc/canvas/2dcontext-caret.html#focus-management
Comment 11 Michael Cooper 2010-09-28 15:32:24 UTC
http://www.w3.org/2010/09/28-a11y-bugs-minutes.html Bugs 10248 and 10249 were split out from this bug; resolving them should resolve this one.
Comment 12 LĂ©onie Watson 2012-11-15 17:14:54 UTC
Canvas now has a drawSystemFocusRing() and drawCustomFocusRing(). Also the new hit testing functionality for Paths will allow an AT to zoom into objects providing the author does the binding between the path and fallback content objects.

Note: the user agent implementation guide must provide mappings in response to both these changes.